By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,670 Members | 1,554 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,670 IT Pros & Developers. It's quick & easy.

problem in using [ ] operator

P: n/a
Hi all,
I have a problem in accessing elements using overloaded operator [].
Consider,
const int SIZE=10;
int FALSE=0;
class Array
{
private:
int x[SIZE];
public:
//overloading []
int& operator [] (int index)
{
if ( index < 10 )
return x;
else
return FALSE;
}
};

class Base
{
private:
int i;
Array *p[2];
public:
Base ()//Here how to initiaze pointer with initialization
list
{
for(i=0; i<SIZE; i++)
//here how to assign value to array x{SIZE] in
class Array
}

void Display()
{
for(i=0; i<SIZE; i++)
//here also how show value
}
};
int main()
{
Base b;
b.Display();
}

I can directly use x[SIZE] in class Base, but with this object size of
Base will
increase drastically if the value of SIZE takes higher value , so I
want to keep size of Base as minimum as possible.

Plz , clarify me with your suggestions,
Thanks in advance
Bangalore

Sep 16 '05 #1
Share this Question
Share on Google+
24 Replies


P: n/a

Bangalore wrote:
Hi all,
I have a problem in accessing elements using overloaded operator [].
Consider,
const int SIZE=10;
int FALSE=0;
Do not use UPPERCASE for constants. UPPERCASE should be use for macroes
only. class Array
{
private:
int x[SIZE];
public:
//overloading []
int& operator [] (int index)
{
if ( index < 10 )
return x;
else
return FALSE;
}
The compiler is happy with this, I'm not. If you discover an error, you
should normally throw. This is your only option here (except for using
a global variable for passing error-information). };

class Base
{
private:
int i;
Array *p[2];
public:
Base ()//Here how to initiaze pointer with initialization
You most certainly should not use a pointer here. Probably you meant
Array p[2]?
Also there is no parameter to Base so im uncertain as to what you mean
with "initialization". list
{
for(i=0; i<SIZE; i++)
//here how to assign value to array x{SIZE] in
class Array
}

void Display()
{
for(i=0; i<SIZE; i++)
//here also how show value
}
};
int main()
{
Base b;
b.Display();
}

I can directly use x[SIZE] in class Base, but with this object size of
Base will
increase drastically if the value of SIZE takes higher value , so I
want to keep size of Base as minimum as possible.
If you want Base to hold a variable number of Array-memberts, I would
recommend that you use std::vector.

(std::vector< Array > p; in your declaration of Base).
Plz , clarify me with your suggestions,
Thanks in advance
Bangalore


/Peter

Sep 16 '05 #2

P: n/a
> class Array
{
private:
int x[SIZE];
public:
//overloading []
int& operator [] (int index)
{
if ( index < 10 )
return x;
else
return FALSE;
}


Shouldn't be there:
if (index < SIZE )
return x[index];
else
return FALSE;

Sep 16 '05 #3

P: n/a

lokki wrote:
class Array
{
private:
int x[SIZE];
public:
//overloading []
int& operator [] (int index)
{
if ( index < 10 )
return x;
else
return FALSE;
}


Shouldn't be there:
if (index < SIZE )
return x[index];
else
return FALSE;


Surely you should prefer the use of symbolic names, but that is not the
worst problem here.

/Peter

Sep 16 '05 #4

P: n/a

<peter.koch.larsen wrote:
Bangalore wrote:
const int SIZE=10;
int FALSE=0;


Do not use UPPERCASE for constants. UPPERCASE should be use for macroes
only.


This is just a style issue, and many experts would not agree that one should
always follow your rule. For example, in Item 17 of C++ Coding Standards,
Sutter and Alexandrescu use UPPERCASE for namespace-level constants - as the
OP's are.

Best regards,

Tom
Sep 16 '05 #5

P: n/a
Peter thanks for your suggestions,

There is no wrong with Array *p[2] , here I want to declare array of
two class pointers. I made it array because in Base class this
(Array *p[2]) takes only 4 bytes regardless of array size( x[SIZE}
) in Array class.
If it is Array p[2], the size of two objects of class Array will be
added to
the size of Base , which I don't want.

And about constructor "Base()",
Since I am declaring array of two pointers to Array class, I think
these needs
to be initialized using initialization list. I don't know how to
initialize these pointers with initialization list.

overloaded [] operator, which I had given in the source code works
well for the reference object for class Array, but not for array of
pointer to class. I don't know how to implement this ,for array
of pointers.

Plz clarify me.
Thanks,
Bangalore

Sep 16 '05 #6

P: n/a

Thomas Tutone wrote:
<peter.koch.larsen wrote:
Bangalore wrote:
const int SIZE=10;
int FALSE=0;
Do not use UPPERCASE for constants. UPPERCASE should be use for macroes
only.


This is just a style issue, and many experts would not agree that one should
always follow your rule. For example, in Item 17 of C++ Coding Standards,
Sutter and Alexandrescu use UPPERCASE for namespace-level constants - as the
OP's are.


This is a purely subjective matter, but I'm positive that there are not
many experts that in general will disagree with me. I don't have
Sutters and Alexandrescus book here, but even if they disagree (which I
doubt), I'm positive that I will still have the majority of experts on
my side.

Kind regards
Peter

Best regards,

Tom


Sep 16 '05 #7

P: n/a
one correction , Array *p[2] , takes 8 bytes
Thanks,
Bangalore

Sep 16 '05 #8

P: n/a
Bangalore wrote:

[snip]

I am still not sure what all of this should eventually lead to.
So may I ask: What is your real problem?
Don't show us what you think the solution to your problem is and what
problems you have with that solution. What is your first hand problem
that you try to solve with that code?
And yes: I think Peter is still right: Whatever your problem might
be, std::vector most likely would be a solution to it.

--
Karl Heinz Buchegger
kb******@gascad.at
Sep 16 '05 #9

P: n/a

Bangalore wrote:
Peter thanks for your suggestions,

There is no wrong with Array *p[2] , here I want to declare array of
two class pointers. I made it array because in Base class this
(Array *p[2]) takes only 4 bytes regardless of array size( x[SIZE}
) in Array class.
It is unclear how many Array-elements, you might want to store in a
Base. If it is one or two, I do understand you might prefer not to use
the vector, but i still recommend that class. It probably only takes up
twelve bytes on your implementation and this is comparable to what you
use now.
If you always want two Array-objects, the best thing to do is to have
them in Base by value. This gives you the easiest code to manage.
Your idea with pointers is - simply put - difficult to implement and
you are IMHO not qualified to implement that solution yet. I sense you
are learning C++ now, and the best thing you can do is to use the
standard library whenever you can.

If it is Array p[2], the size of two objects of class Array will be
added to
the size of Base , which I don't want.

And about constructor "Base()",
Since I am declaring array of two pointers to Array class, I think
these needs
to be initialized using initialization list. I don't know how to
initialize these pointers with initialization list.
You can't initialise an array in a constructor. You need to do p[0] =
0; p[1] = 0; (or something smarter such as std::fill).
overloaded [] operator, which I had given in the source code works
well for the reference object for class Array, but not for array of
pointer to class. I don't know how to implement this ,for array
of pointers.
It does not work well. Array[47] returns a perfectly fine int and I bet
that is not what the class should do. You can even do Array[47] = 10;
Array[48] = 11;. Guess what the value of Array[47] is now.

Plz clarify me.
Thanks,
Bangalore


/Peter

Sep 16 '05 #10

P: n/a

pe***************@gmail.com wrote:
Thomas Tutone wrote:
<peter.koch.larsen wrote:
Bangalore wrote:
> const int SIZE=10;
> int FALSE=0;

Do not use UPPERCASE for constants. UPPERCASE should be use for macroes
only.


This is just a style issue, and many experts would not agree that one should
always follow your rule. For example, in Item 17 of C++ Coding Standards,
Sutter and Alexandrescu use UPPERCASE for namespace-level constants - as the
OP's are.


This is a purely subjective matter, but I'm positive that there are not
many experts that in general will disagree with me. I don't have
Sutters and Alexandrescus book here, but even if they disagree (which I
doubt), I'm positive that I will still have the majority of experts on
my side.


Ummm... OK, I'll bite. Please cite some experts who state "one should
use uppercase only for macros, and not for global constants." Since
I've already cited two experts who in fact on occasion use uppercase
for global constants - and in a book that's less than a year old -
you're going to need to come up at least three to have any chance at a
"majority."

My point was simply that you presented as an objective truth something
that, as you now state, is purely subjective.

Cheers!

Tom

Sep 16 '05 #11

P: n/a

Thomas Tutone skrev:
pe***************@gmail.com wrote:
Thomas Tutone wrote:
<peter.koch.larsen wrote:

> Bangalore wrote:
>> const int SIZE=10;
>> int FALSE=0;
>
> Do not use UPPERCASE for constants. UPPERCASE should be use for macroes
> only.

This is just a style issue, and many experts would not agree that one should
always follow your rule. For example, in Item 17 of C++ Coding Standards,
Sutter and Alexandrescu use UPPERCASE for namespace-level constants - as the
OP's are.
This is a purely subjective matter, but I'm positive that there are not
many experts that in general will disagree with me. I don't have
Sutters and Alexandrescus book here, but even if they disagree (which I
doubt), I'm positive that I will still have the majority of experts on
my side.


Ummm... OK, I'll bite. Please cite some experts who state "one should
use uppercase only for macros, and not for global constants." Since
I've already cited two experts who in fact on occasion use uppercase
for global constants - and in a book that's less than a year old -
you're going to need to come up at least three to have any chance at a
"majority."

My point was simply that you presented as an objective truth something
that, as you now state, is purely subjective.


Surely this is a subjective matter as there's nothing in the C++
standard that mandates that this should be so. Still I believe to be in
very good company. If you look at Item 16 in C++ Coding Standards,
you'll notice this advice:
"... always give them [macroes] SCREAMING_UPPERCASE_AND_UGLY names" and
"never ever even consider starting to think about writing a macro that
is a common word or abbreviation"." While they do not directly state
that non-macroes shouldn't be all uppercase, it is clearly the
intention that the naming convention is made to avoid nameclashes with
nonmacroes. As for item 17, I could imagine that the example is a
header where #defines have been changed to consts and thus the original
names have been preserved.
Apart from that I believe to have lots of respected folks who share my
opinion - a quick Google-search on comp.lang.c++ gave me names such as
Alf Steinberg, Rolf Magnus, Paul Mensonides and Rob Williscroft. Never
ever have I seen advice to have non-macro names in all-upppercase.

Cheers!

Tom


/Peter

Sep 16 '05 #12

P: n/a
pe***************@gmail.com wrote:
Never ever have I seen advice to have non-macro names in all-upppercase.


You're kidding me.

Sep 16 '05 #13

P: n/a
pe***************@gmail.com wrote:
This is a purely subjective matter, but I'm positive that there are not
many experts that in general will disagree with me. I don't have
Sutters and Alexandrescus book here, but even if they disagree (which I
doubt), I'm positive that I will still have the majority of experts on
my side.


The existence of an hypotetical swarm of experts claiming that uppercase
names are evil is of absolutely no value to this suject. This
pseudo-problem does not have it's base on technical issues. It is a matter
of code style and personal taste and until proven otherwise (a simple "I
don't know where but there are tons of experts that agree with me" doesn't
cut it) this isn't a problem at all.
Best regards
Rui Maciel
--
Running Kubuntu 5.04 with KDE 3.4.2 and proud of it.
jabber:ru********@jabber.org
Sep 17 '05 #14

P: n/a
* Rui Maciel:
* Peter Koch Larsen:
This is a purely subjective matter, but I'm positive that there are not
many experts that in general will disagree with me. I don't have
Sutters and Alexandrescus book here, but even if they disagree (which I
doubt), I'm positive that I will still have the majority of experts on
my side.
The existence of an hypotetical swarm of experts claiming that uppercase
names are evil is of absolutely no value to this suject. This
pseudo-problem does not have it's base on technical issues.


It is in fact a real problem, or set of problems, and the original problem is
in fact a problem rooted in a clear technical issue, namely that macros are
simple text substitutions that don't respect namespaces or scopes, or type
rules. A secondary, derived problem is that Java adopted the C naming
convention for constants, where, since C didn't have typed constants, that was
the convention for macros. One aspect of this derived problem is that it
makes it difficult to have one common coding standard for a multi-language
project, and another aspect is that Java programmers who migrate to C++ keep
their conventions that worked well in Java, but just wreak havoc in C++.

Anyway, I think you should listen to the experts also in matters of judgement.
If you don't agree after having considered their advice & opinions, then that
might bring the state of knowledge one bit further. But first consider.

E.g., check out <url: http://www.research.att.com/~bs/bs_faq2.html#macro>,
where "bs" does not stand for an 8-letter word but for "Bjarne Stroustrup".

Or you might check the macro names in e.g. the C++ FAQ.

Curiously this issue isn't explicitly discussed in the FAQ, AFAICS, but the
naming convention adopted speaks for itself, as well as tidbits such item 33.5
having been updated in the 12/02 release, "renamed the macro to all-caps",
which presumably wouldn't have been done if it didn't matter.

It is a matter
of code style and personal taste and until proven otherwise


Consider it proven otherwise (see above). ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Sep 17 '05 #15

P: n/a

"Alf P. Steinbach" <al***@start.no> wrote in message
news:43****************@news.individual.net...
* Rui Maciel:
* Peter Koch Larsen:
> This is a purely subjective matter, but I'm positive that there are not
> many experts that in general will disagree with me. I don't have
> Sutters and Alexandrescus book here, but even if they disagree (which I
> doubt), I'm positive that I will still have the majority of experts on
> my side.


The existence of an hypotetical swarm of experts claiming that uppercase
names are evil is of absolutely no value to this suject. This
pseudo-problem does not have it's base on technical issues.


It is in fact a real problem, or set of problems, and the original problem
is
in fact a problem rooted in a clear technical issue, namely that macros
are
simple text substitutions that don't respect namespaces or scopes, or type
rules. A secondary, derived problem is that Java adopted the C naming
convention for constants, where, since C didn't have typed constants, that
was
the convention for macros. One aspect of this derived problem is that it
makes it difficult to have one common coding standard for a multi-language
project, and another aspect is that Java programmers who migrate to C++
keep
their conventions that worked well in Java, but just wreak havoc in C++.

Anyway, I think you should listen to the experts also in matters of
judgement.
If you don't agree after having considered their advice & opinions, then
that
might bring the state of knowledge one bit further. But first consider.

E.g., check out <url: http://www.research.att.com/~bs/bs_faq2.html#macro>,
where "bs" does not stand for an 8-letter word but for "Bjarne
Stroustrup".

Or you might check the macro names in e.g. the C++ FAQ.

Curiously this issue isn't explicitly discussed in the FAQ, AFAICS, but
the
naming convention adopted speaks for itself, as well as tidbits such item
33.5
having been updated in the 12/02 release, "renamed the macro to all-caps",
which presumably wouldn't have been done if it didn't matter.

It is a matter
of code style and personal taste and until proven otherwise


Consider it proven otherwise (see above). ;-)


Umm... "Conventions such as having macros (and only macros) in ALLCAPS
helps, but there is no language-level protection against macros." is proof?
No where does that line say it should be done. Nor does it even suggest it.
It just says "helps".

Personally I tend to make all Global variables (macro or not) all caps
because I hate all caps and it gives me more incentive to find some better
way to do it as soon as I can.

But it also lets me know that if I see something in all caps the scope is
greater than the current function/method and I better be careful with it.
Sep 17 '05 #16

P: n/a
* Jim Langston, quoting Bjarne Stroustrup's C++ FAQ:

Umm... "Conventions such as having macros (and only macros) in ALLCAPS
helps, but there is no language-level protection against macros." is proof?
No where does that line say it should be done. Nor does it even suggest it.
If you don't count that as even a suggestion, then you have what I consider a
very odd notion of what constitutes a suggestion.

Personally I tend to make all Global variables (macro or not) all caps
because I hate all caps and it gives me more incentive to find some better
way to do it as soon as I can.
How about finding a convention that is not all caps and that you hate just as
much or more? Try e.g. "g_l_o_b_a_l_" as a prefix. That will really hurt (I
hope), and then really expedite the get-rid-of-em response, and also lower the
probability of name collision with macros: it's win win all the way.

But it also lets me know that if I see something in all caps the scope is
greater than the current function/method and I better be careful with it.


If it isn't all caps, then it isn't global, hence the scope isn't greater than
the current function, and hence more careless programming is indicated, which
is good. Hum. I'm not sure I followed that, but if it works, by all means.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Sep 17 '05 #17

P: n/a

Rui Maciel skrev:
pe***************@gmail.com wrote:
This is a purely subjective matter, but I'm positive that there are not
many experts that in general will disagree with me. I don't have
Sutters and Alexandrescus book here, but even if they disagree (which I
doubt), I'm positive that I will still have the majority of experts on
my side.
The existence of an hypotetical swarm of experts claiming that uppercase
names are evil is of absolutely no value to this suject. This
pseudo-problem does not have it's base on technical issues. It is a matter
of code style and personal taste and until proven otherwise (a simple "I
don't know where but there are tons of experts that agree with me" doesn't
cut it) this isn't a problem at all.

First of all, this is not a pseudo-problem. Anyone who has tried using
std::max or std::min while including windows know that.
For the technical merit, the advantage of adhering to the convention of
using only all-caps for macroes manifests itself as the consequence of
this is that macroes then will not interfere with any language parts.
The only interference is between competing macroes.

Best regards
Rui Maciel
--


/Peter

Sep 18 '05 #18

P: n/a
I am still not sure what all of this should eventually lead to.
So may I ask: What is your real problem?
Don't show us what you think the solution to your problem is and what
problems you have with that solution. What is your first hand problem
that you try to solve with that code?

Actually I am facing this problem in my project, Here if at all ,I
include those array elements in my Base class ,size of the base class
will increase,this leads to change in architecture of that object , If
I change that object, it has a huge impact on my code.

With rererence vaibles , there is code snippet
--------- Before slipt: -----------
class B
{
public:
B(){};
A a;
}

++++++++ After split +++

#include<iostream.h>

class A
{
public:
A():i(9){};
int i; //I want to declare int i[10] as private, for data
hiding purpose
};

class B
{
public:
B():a(*(new A())){};
A& a; //Desperately I want to use array of two pointers
};

main()
{
B b;
cout << b.a.i;
}
)

{

B b;

cout << b.a.i;

}


And yes: I think Peter is still right: Whatever your problem might
be, std::vector most likely would be a solution to it.

I don't want to use vectors here.
--
Karl Heinz Buchegger
kb******@gascad.at[/quote]

Sep 19 '05 #19

P: n/a
> Bangalorewrote:
I am still not sure what all of this should eventually lead to.
So may I ask: What is your real problem?
Don't show us what you think the solution to your problem is and what problems you have with that solution. What is your first hand problem that you try to solve with that code?

Actually I am facing this problem in my project, Here if at all ,I include those array elements in my Base class ,size of the base class
will increase,this leads to change in architecture of that object , If
I change that object, it has a huge impact on my code.
With rererence vaibles , there is code snippet
--------- Before slipt: -----------
class B
{
public:
B(){};
A a;
}

++++++++ After split +++

#include<iostream.h>

class A
{
public:
A():i(9){};
int i; //I want to declare int i[10] as private, for data hiding purpose };

class B
{
public:
B():a(*(new A())){};
A& a; //Desperately I want to use array of two pointers
};

main()
{
B b;
cout << b.a.i;
}
)

{

B b;

cout << b.a.i;

}


And yes: I think Peter is still right: Whatever your problem might
be, std::vector most likely would be a solution to it.

I don't want to use vectors here.
--
Karl Heinz Buchegger
kb******@gascad.at[/quote]


Sep 19 '05 #20

P: n/a
> Bangalorewrote:
[quote:c9ec9cc6ef]I am still not sure what all of this should
eventually lead to.
So may I ask: What is your real problem?
Don't show us what you think the solution to your problem is and what problems you have with that solution. What is your first hand problem that you try to solve with that code?
Actually I am facing this problem in my project, Here if at all ,I
include those array elements in my Base class ,size of the base class
will increase,this leads to change in architecture of that object , If
I change that object, it has a huge impact on my code.

With rererence vaibles , there is code snippet
--------- Before slipt: -----------
class B
{
public:
B(){};
A a;
}

++++++++ After split +++

#include<iostream.h>

class A
{
public:
A():i(9){};
int i; //I want to declare int i[10] as private, for data
hiding purpose
};

class B
{
public:
B():a(*(new A())){};
A& a; //Desperately I want to use array of two pointers
};

main()
{
B b;
cout << b.a.i;
}
)

{

B b;

cout << b.a.i;

}

And yes: I think Peter is still right: Whatever your problem might
be, std::vector most likely would be a solution to it.


I don't want to use vectors here.
--
Karl Heinz Buchegger
kb******@gascad.at[/quote:c9ec9cc6ef][/quote][quote:c9ec9cc6ef][/quote:c9ec9cc6ef]

Sep 19 '05 #21

P: n/a
Bangalore wrote:
Bangalorewrote:
[quote:c9ec9cc6ef]I am still not sure what all of this should
eventually lead to.
So may I ask: What is your real problem?
Don't show us what you think the solution to your problem is and


what
problems you have with that solution. What is your first hand


problem
that you try to solve with that code?

Actually I am facing this problem in my project, Here if at all ,I
include those array elements in my Base class ,size of the base class
will increase,this leads to change in architecture of that object , If
I change that object, it has a huge impact on my code.

With rererence vaibles , there is code snippet
--------- Before slipt: -----------
class B
{
public:
B(){};
A a;
}

++++++++ After split +++

#include<iostream.h>

class A
{
public:
A():i(9){};
int i; //I want to declare int i[10] as private, for data
hiding purpose
};

class B
{
public:
B():a(*(new A())){};
A& a; //Desperately I want to use array of two pointers


B(): { a[0] = new A(); a[1] = new A(); }
A* a[2];

What is the problem?
};

main()
{
B b;
cout << b.a.i;
}
)

{

B b;

cout << b.a.i;

}


And yes: I think Peter is still right: Whatever your problem might
be, std::vector most likely would be a solution to it.

I don't want to use vectors here.


You've got three choices.

1) Use an array, you already said you don't want to do that.

2) Use a vector, you've just said you don't want to do that (why?).

3) Use pointers.

I have to say I don't think there is any problem here. You seem to be
seeing problems that don't exist.

john
Sep 19 '05 #22

P: n/a
>
B(): { a[0] = new A(); a[1] = new A(); }
A* a[2];

What is the problem?

I have problem in accsessing array elements using overloaded []
operator.I
have slightly modied code for array of pointers.

class A
{
int a[1000]; // declaring int a[10] as private, for data hiding
purpose
public:
A():{};
int i;

//overload [] operator
int& operator [] (int index)
{
//some range checking can be done
return a;
}
};

};
class B
{
A* a[2]; //declaring in private part for data hiding.
public:
B():
{
a[0]=new A();
a[1]=new A();
}

//I need to overload [] operator here so that
//in main function I can directly use objects of
//this class
};
int main()
{

B base;
// Here I wanted to fill the values for array in class A(i.e int
a[100]);
//How can I do it here?????
}


You've got three choices.

1) Use an array, you already said you don't want to do that.

2) Use a vector, you've just said you don't want to do that (why?).

3) Use pointers.
Here I am using array of pointers
I have to say I don't think there is any problem here. You seem to be seeing problems that don't exist.

I am finding problem in implementing overloaded operator [] in class B
and
Filling array elements in main()

Thanks
Bangalore]

Sep 19 '05 #23

P: n/a
Bangalore wrote:

B(): { a[0] = new A(); a[1] = new A(); }
A* a[2];

What is the problem?

I have problem in accsessing array elements using overloaded []
operator.I
have slightly modied code for array of pointers.

class A
{
int a[1000]; // declaring int a[10] as private, for data hiding
purpose
public:
A():{};
int i;

//overload [] operator
int& operator [] (int index)
{
//some range checking can be done
return a;


You don't want to return a here. a is an array.
You want to return a reference to one specific array
element.

return a[index]; }
};

};
class B
{
A* a[2]; //declaring in private part for data hiding.
public:
B():
{
a[0]=new A();
a[1]=new A();
}

//I need to overload [] operator here so that
//in main function I can directly use objects of
//this class
};
int main()
{

B base;
// Here I wanted to fill the values for array in class A(i.e int
a[100]);
//How can I do it here?????
Well.
Think of some syntax you want to use.
How would you have it look like?
I am finding problem in implementing overloaded operator [] in class B
and
Filling array elements in main()


What should that operator do?
eg. map all index values from 0 to 999 to *a[0]
and all index values from 1000 to 1999 to *a[1]

hint: the above already contains a hint in how the
syntax should look like. a is a poitner. Dereferencing
that pointer lets you get your hands at the underlying
object. If in doubt, a few '(' ')' are most often a good
idea to clear things up.

int& B::operator[] (int index)
{
if( index < 1000 )
return (*(a[0]))[index];
else
return (*(a[1]))[index];
}

a the array of pointers
a[0] one element of that array -> one pointer
*(a[0]) dereference the pointer -> the underlaing class A object
(*(a[0])) [index] use operator[] from that class A object

--
Karl Heinz Buchegger
kb******@gascad.at
Sep 19 '05 #24

P: n/a
Thanks all for your suggestions and hints
Regards,
Bangalore

Sep 20 '05 #25

This discussion thread is closed

Replies have been disabled for this discussion.