Overloading operator []

I have not posted to comp.lang.c++ (or comp.lang.c++.m oderated)
before. In general when I have a C++ question I look for answers in
"The C++ Programming Language, Third Edition" by Stroustrup.
However, I've come upon a question that I can neither answer from
"The Book" or a Google search (so yes, at least I RTFBed). I'm
hoping that someone in this news group might know the answer.

Overloading the [] Operator

Say I want to develop a class that supports the overloaded []
operator and reads and writes the "int" type. I thought that the
way this was done was:

class MyClass
{
//...
// in theory, the RHS operator
const int operator[](const int i ) const;
// in theory, the LHS operator
int& operator[](const int i );
//...
}

Here RHS stands for right-hand-side, or an r-value and LHS stands
for left-hand-side, or an l-value.

MyClass foo;

int i = foo[j]; // RHS reference NOT!
foo[j] = i; // LHS reference

Much to my surprise, the first statement "i = foo[j];" seems to
invoke the overloaded operator I've labeled LHS. I tried this with
Microsoft's Visual C++ 6.0 compiler, I think upgraded with at least
service pack 5 (version 12.00.8804) and the GNU 2.95.2 g++ compiler
for Intel on freeBSD. Both compilers got the same results.

To put things in more concrete form, I've included a complete test
code below:

#include <stdio.h>

class overloaded
{
private:
int *pArray;

public:
overloaded( size_t size )
{
pArray = new int[ size ];
}

~overloaded()
{
delete [] pArray;
}

// in theory, the RHS operator
const int operator[](const int i ) const
{
printf("RHS a[%2d]\n", i );
return pArray[i];
}

// in theory, the LHS operator
int& operator[](const int i )
{
printf("LHS a[%2d]\n", i );
return pArray[i];
}
}; // overloaded
int
main()
{
const int len = 4;
overloaded a(len);
int b[len];

int i;

printf("initial izing array...\n");
for (i = 0; i < len; i++) {
a[i] = i + 1;
}

printf("reading values from array in an 'if' statement...\n" );
for (i = 0; i < len; i++) {
if (a[i] != i+1) {
printf("bad value");
break;
}
}

printf("reading values from an array in an assignment...\n ");
for (i = 0; i < len; i++) {
b[i] = a[i];
}

printf("express ion...\n");
int j = a[1] + a[2];
return 0;
}

When I compile and execute this code I get

initializing array...
LHS a[ 0]
LHS a[ 1]
LHS a[ 2]
LHS a[ 3]
reading values from array in an 'if' statement...
LHS a[ 0]
LHS a[ 1]
LHS a[ 2]
LHS a[ 3]
reading values from an array in an assignment...
LHS a[ 0]
LHS a[ 1]
LHS a[ 2]
LHS a[ 3]
expression...
LHS a[ 1]
LHS a[ 2]

I expected that the "initialization " would reference the LHS form of
the overloaded function. However, much to my surprise, the 'if'
statement and the value reads also referenced the LHS form of the
overloaded operator. I'm surprised at this, since as far as I can
tell, this way I've implemented the overloaded [] operators is
pretty much "text book" approach.

Is there a way to implement this class so that the RHS [] will be
called when it seems to be an r-value? That is

if (a[i] != i+1)
b[i] = a[i];
int j = a[1] + a[2];

In this example the difference is not critical, since the code gets
the expected results. However, proper invokation of the RHS and LHS
operators is important in the case of reference counted objects,
which is the appliction that originally motivated this question.

I'm working on a third version of a reference counted String class,
which can be found here:
http://www.bearcave.com/software/string/index.html. This class
suffers from a bug caused by the behavior of the [] operator
described above. In particular, it is making too many copies.

I have noted Stroustrup's solution using the Cref class (from 11.12
of "The Book"). However, in his code it appears that you might as
well omit the RHS version of the [] operator.

I'd be grateful for a version of the test code above that invokes
the RHS operator for what appear to be r-value references. Could
you please copy any postings on this to "iank at bearcave dot com".
Thank you for your help,

Ian
iank at bearcave dot com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[kanze]

"Siemel Naran" <Si*********@RE MOVE.att.net> wrote in message
news:<6X******* **************@ bgtnsc04-news.ops.worldn et.att.net>...

"Francis Glassborow" <fr************ ****@ntlworld.c om> wrote in message

> Siemel Naran <Si*********@RE MOVE.att.net> writes

> >How do you deal with the problem of replicating the interface of
> >class bool in class hue::ref? No problem with class bool as you
> >only have to worry about operator= as you did above (and I did in
> >my example). But what about other member functions like
> >operator+=, memfun(), etc?

> Sorry, I am totally confused. bool is a fundamental type and not a
> class. Operator bool 'returns' a bool by value.

Say you have a class Foo. The operator[] that is non-const returns a
proxy. There is a function operator const Foo&() const. Then there
is a function void operator=(const Foo&). What about other member
functions of class Foo? So that we can say EnvelopeClass env;
env["abc"]; // returns EnvelopeClass:: reference, which is conceptually a
Foo&
env["abc"] = Foo(3); // ok
env["abc"].memfun(); // oops For the last line to work, class EnvelopeClass:: reference should have
a member function memfun() because class Foo has such a function.
Then we have to duplicate the entire interface of class Foo inside
Foo::reference. Quite a nuisance.

This is a known problem. It is a major motivation behind the desire to
be able to overload operator.(). In the meantime, about the best you
can do is overload operator-> on the proxy, and require your users to
write things like:

env[ "abc" ]->memfun() ;

It exposes the fact that you are using a proxy, but until you can
overload operator.(), it is the best you can do.

--
James Kanze GABI Software mailto:ka***@ga bi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientier ter Datenverarbeitu ng
11 rue de Rambouillet, 78460 Chevreuse, France, [phone]

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[kanze]

Thomas Mang <a9******@unet. univie.ac.at> wrote in message
news:<3F******* ********@unet.u nivie.ac.at>...

James Kanze schrieb:

> Normally, this should not be a problem. There are exceptions,
> however, when you need to do something different if the target is
> actually modified. In such cases, you typically need to use some sort
> of Proxy, e.g.:

[Code deleted...]
What advantage does one gain by writing a proxy class, instead of
simply returning an int&? That is, why not simply write the following overloaded operator[]? int& operator[](int index)

If you can return a reference, you do. If you can't, you use a proxy.

References can be dangerous, because they allow the user direct access
to your internals. Thus, for exemple, the problemes with COW with
std::string -- if std::string::op erator[] were allowed to return a
proxy, COW would be a lot easier, *and* would be a much bigger win.

Or consider a class which actually maintains the data on disk, and not
in memory. If the accesses are all through get and put (called by the
proxy), there is no problem; if you return a reference, however, you
don't know how long to lock the data in memory, and you don't know after
whether it has been modified or not, so you don't know whether you have
to write the data back or not.

--
James Kanze GABI Software mailto:ka***@ga bi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientier ter Datenverarbeitu ng
11 rue de Rambouillet, 78460 Chevreuse, France, [phone]

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Francis Glassborow]

In message <3F************ **@hotmail.com> , Andrey Tarasevich
<an************ **@hotmail.com> writes

Not true. We gave user full control of the value, which doesn't
necessarily mean that we "lost" control of it in negative sense of the
word, since the object that returned the reference might not even care
about this control.
But that is a design decision, and if you truly do not care make the
data public.

The main motive for
having private data is exactly to avoid such circumstances. If a member
function returns a plain reference we might as well make the data
public.
...

Not true.

There still is one (although thin) level of protection that is not
destroyed by returning a reference to private data. It doesn't expose
the actual location of the lvalue, i.e. it doesn't declare loud and
clear that the returned reference is bound to a subobject of the class.
Making a subobject 'public' immediately removes this last layer of
protection.

For example, making a subobject 'public' allows user to make assumptions
about the lifetime of subobject based on the lifetime of the entire
object. Accessor member function that returns a reference prevents user
to make such assumptions.

The subtle problems that this introduces are well illustrated by the
c_str() member of std::string.

Now I over stated my case because containers have internal data
structures that we do not want to expose to users, yet we do want to
provide full access to the contained objects. Generally that is easily
supplied by either references or iterators. Sometimes such as in the
case of bitset<> we cannot do that and have to provide a proxy to do the
work but that is a different design problem because the individual
elements do not have independent existence.

--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[llewelly]

Andrey Tarasevich <an************ **@hotmail.com> writes:

Francis Glassborow wrote:

> ...
> No, you are making assumptions as to what the class designer should
> expose. The point of using a proxy class is exactly that it give the
> class designer control whilst the return of a reference abandons it.
> If
> we write any function that returns a plain reference to private data we
> have exposed that data and lost control of it.
Not true. We gave user full control of the value, which doesn't
necessarily mean that we "lost" control of it in negative sense of the
word, since the object that returned the reference might not even care
about this control.

This is hairsplitting on the definition of control.

> The main motive for
> having private data is exactly to avoid such circumstances. If a member
> function returns a plain reference we might as well make the data
> public.
> ...
Not true.

There still is one (although thin) level of protection that is not
destroyed by returning a reference to private data. It doesn't expose
the actual location of the lvalue,

That depends on what you mean by location. The address of the lvalue
is exposed.
i.e. it doesn't declare loud and
clear that the returned reference is bound to a subobject of the
class.
#include<iostre am>

class a
{
int i;
public:
int& foo(){return i;}
};

bool is_within(void* p, void* begin, void* end)
{
return p >= begin and p < end ;
}

int main()
{
a b;
std::cout << std::boolalpha << "is_within(&b.f oo(), &b, &b + 1) == "
<< is_within(&b.fo o(), &b, &b + 1) << std::endl;
}
I believe the expression 'is_within(&b.f oo(), &b, &b + 1)' in the
above is required to return true.
Making a subobject 'public' immediately removes this last layer of
protection.

[snip]

I used to think so too. Then I encountered a real-life situation
where someone had come to rely on what is implied by the code
above.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Siemel Naran]

<ka***@gabi-soft.fr> wrote in message

"Siemel Naran" <Si*********@RE MOVE.att.net> wrote in message

For the last line to work, class EnvelopeClass:: reference should have
a member function memfun() because class Foo has such a function.
Then we have to duplicate the entire interface of class Foo inside
Foo::reference. Quite a nuisance.

This is a known problem. It is a major motivation behind the desire to
be able to overload operator.(). In the meantime, about the best you
can do is overload operator-> on the proxy, and require your users to
write things like:

env[ "abc" ]->memfun() ;

It exposes the fact that you are using a proxy, but until you can
overload operator.(), it is the best you can do.

So essentially operator[] returns a proxy pointer. However I'm not sure if
it solves the original problem. For const member functions we just want to
forward to real function. For non-const member functions we want to call
the alter function and then forward to the real function.

class Envelope::Refer ence {
public:
void constmemfun() const {
return d_object.constm emfun();
}
void memfun() const {
d_envelope.alte r();
return d_object.memfun ();
}
private:
Envelope& d_envelope;
Envelope::Objec t& d_object;
};

--
+++++++++++
Siemel Naran
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[kanze]

"Siemel Naran" <Si*********@RE MOVE.att.net> wrote in message
news:<70******* **************@ bgtnsc05-news.ops.worldn et.att.net>...

<ka***@gabi-soft.fr> wrote in message

"Siemel Naran" <Si*********@RE MOVE.att.net> wrote in message

For the last line to work, class EnvelopeClass:: reference should
have a member function memfun() because class Foo has such a
function. Then we have to duplicate the entire interface of class
Foo inside Foo::reference. Quite a nuisance.

This is a known problem. It is a major motivation behind the desire
to be able to overload operator.(). In the meantime, about the best
you can do is overload operator-> on the proxy, and require your
users to write things like: env[ "abc" ]->memfun() ; It exposes the fact that you are using a proxy, but until you can
overload operator.(), it is the best you can do.

So essentially operator[] returns a proxy pointer.
Sort of a mixure. It acts like an object on the left side of
assignment, and when an lvalue to rvalue conversion is called for, but
like a pointer if you use the -> operator:-). Not an ideal situation, I
will admit.
However I'm not sure if it solves the original problem. For const
member functions we just want to forward to real function. For
non-const member functions we want to call the alter function and then
forward to the real function. class Envelope::Refer ence {
public:
void constmemfun() const {
return d_object.constm emfun();
}
void memfun() const {
d_envelope.alte r();
return d_object.memfun ();
}
private:
Envelope& d_envelope;
Envelope::Objec t& d_object;
};

Yet another problem.

In practice, I have only used such proxies within collections, and my
collections, like the STL, use value semantics. So you typically don't
have non-const member functions except for assignment; you also tend to
copy the object you're interested in out of the collection, and work
with the copy, potentially copying it back in.

I suppose if I had to deal with objects with behavior, I'd arrange for
operator[] (or the operator-> of the proxy) to return some sort of smart
pointer -- if the collection is caching objects, for example, you'd need
the smart pointer to tell you when you could free the object, for
example.

--
James Kanze GABI Software mailto:ka***@ga bi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientier ter Datenverarbeitu ng
11 rue de Rambouillet, 78460 Chevreuse, France, [phone]

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Andrey Tarasevich]

llewelly wrote:

>
> There still is one (although thin) level of protection that is not
> destroyed by returning a reference to private data. It doesn't expose
> the actual location of the lvalue,

That depends on what you mean by location. The address of the lvalue
is exposed.

I meant a completely different notion of location (OK, I agree that
"location" is rather bad choice of word). What I meant is explained
below (after "i.e."):

> i.e. it doesn't declare loud and
> clear that the returned reference is bound to a subobject of the
> class.

#include<iostre am>

class a
{
int i;
public:
int& foo(){return i;}
};

bool is_within(void* p, void* begin, void* end)
{
return p >= begin and p < end ;
}

int main()
{
a b;
std::cout << std::boolalpha << "is_within(&b.f oo(), &b, &b + 1) == "
<< is_within(&b.fo o(), &b, &b + 1) << std::endl;
}

I believe the expression 'is_within(&b.f oo(), &b, &b + 1)' in the
above is required to return true.

Yes, in this particular case it is required to return 'true'. (Actually,
reading 5.9/2 I can't immediately say whether the comparison between
'&b.foo()' and '&b + 1' is specified by the standard. But let's assume
that it is.) But this technique cannot legally be used to detect the
situation when the returned reference is bound to a subobject of given
object. The problem arises when the returned reference is _not_ bound to
a subobject. In this case the pointer comparison in the above
'is_within' function is unspecified (see 5.9/2), which means that
basically anything can be returned. In other words, when this function
returns 'true', it means one of two things:

1) pointer 'p' points to some location between 'begin' and 'end'
2) the comparison is unspecified and the returned result is nothing but
an accident - a particular case of unspecified result, that just happens
to be 'true' this time

Can you come up with a way to differentiate these two situations? I
don't believe it is possible.

> Making a subobject 'public' immediately removes this last layer of
> protection.

[snip]

I used to think so too. Then I encountered a real-life situation
where someone had come to rely on what is implied by the code
above.
...

As I said above, this code does not illustrate any legal technique,
which means that I can't accept it as an argument.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[llewelly]

Andrey Tarasevich <an************ **@hotmail.com> writes:

llewelly wrote:

> >
> > There still is one (although thin) level of protection that is not
> > destroyed by returning a reference to private data. It doesn't expose
> > the actual location of the lvalue,

>
> That depends on what you mean by location. The address of the lvalue
> is exposed.

I meant a completely different notion of location (OK, I agree that
"location" is rather bad choice of word). What I meant is explained
below (after "i.e."):

> > i.e. it doesn't declare loud and
> > clear that the returned reference is bound to a subobject of the
> > class.

>
> #include<iostre am>
>
> class a
> {
> int i;
> public:
> int& foo(){return i;}
> };
>
> bool is_within(void* p, void* begin, void* end)
> {
> return p >= begin and p < end ;
> }
>
> int main()
> {
> a b;
> std::cout << std::boolalpha << "is_within(&b.f oo(), &b, &b + 1) == "
> << is_within(&b.fo o(), &b, &b + 1) << std::endl;
> }
>
> I believe the expression 'is_within(&b.f oo(), &b, &b + 1)' in the
> above is required to return true.

Yes, in this particular case it is required to return 'true'. (Actually,
reading 5.9/2 I can't immediately say whether the comparison between
'&b.foo()' and '&b + 1' is specified by the standard. But let's assume
that it is.) But this technique cannot legally be used to detect the
situation when the returned reference is bound to a subobject of given
object. The problem arises when the returned reference is _not_ bound to
a subobject. In this case the pointer comparison in the above
'is_within' function is unspecified (see 5.9/2), which means that
basically anything can be returned. In other words, when this function
returns 'true', it means one of two things:

1) pointer 'p' points to some location between 'begin' and 'end'
2) the comparison is unspecified and the returned result is nothing but
an accident - a particular case of unspecified result, that just happens
to be 'true' this time

[snip]

This is quite similar to my response the first time I encountered this
issue. What I didn't realize is that most real programs must rely
on on some unspecified, undefined, or implementation-defined
behavior (though such code is hopefully labled, conditioned
according to platform, and most importantly confined), and in
certain areas (e.g., implementing garbage collectors) relying on
pointer comparisons is common.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Glen Low]

> No, you are making assumptions as to what the class designer should

expose. The point of using a proxy class is exactly that it give the
class designer control whilst the return of a reference abandons it. If
we write any function that returns a plain reference to private data we
have exposed that data and lost control of it. The main motive for
having private data is exactly to avoid such circumstances. If a member
function returns a plain reference we might as well make the data
public.

In general I agree with you and disagree with the parent post -- it is
dangerous to return references. However there is one other case I can
think of besides containers where you may want to return references:
where you want to restrict to const access.

E.g.
class X
{
private:
Y y_;
public:
const Y& getReference () const { return y_; }
};

Here you don't want to expose the data member y_ to arbritary change,
you want all clients (even those with a non-const reference to an X)
to only be able to see y_ and not change it.

The moral equivalent of:

class X
{
private:
Y y_;
public:
const Y& reference;
X (...): y_ (...), reference (y_) { }
};

.... though I'm not sure by C++ standard rules whether y_ exists at the
right time to get a reference to it.

Cheers,
Glen Low
http://www.pixelglow.com/

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Maciej Sobczak]

Hi,

Glen Low wrote:

The moral equivalent of:

class X
{
private:
Y y_;
public:
const Y& reference;
X (...): y_ (...), reference (y_) { }
};

... though I'm not sure by C++ standard rules whether y_ exists at the
right time to get a reference to it.

Members are initialized in the order of their declaration, independent
of their order in the initializer list.

In other words, 'y_' is initialized before 'reference', so 'reference'
is initialized with a reference to the already initialized 'y_'.

Interestingly:

class X
{
public:
const Y& reference;
X (...): y_ (...), reference (y_) { }
private:
Y y_;
};

Here, 'reference' is initialized with a reference to something that has
not yet been initialized, but that already has memory allocated. This is
a problem, and I cannot find in the Standard any clear statement that
would either bless or damn it. Some compilers accept this code. For
sure, *using* a reference to something that does not yet exist is forbidden.

--
Maciej Sobczak
http://www.maciejsobczak.com/

Distributed programming lib for C, C++, Python & Tcl:
http://www.maciejsobczak.com/prog/yami/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]