Overloading operator []
(null)
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("initializing 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("expression...\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++.moderated. First time posters: Do this! ]
John Harrison
"(null)" <ia...@idiom.com> wrote in message news:1058054598.920916@smirk...
> I have not posted to comp.lang.c++ (or comp.lang.c++.moderated)
> 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 );
> //...
I'd prefer
int operator[](int i ) const;
int& operator[](int i );
for an int type the other const's are unecessary.
Your comments about RHS operator and LHS operator are incorrect however. See
below.
> }
>
> 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.
>
[snip]
>
> 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];
>
It would be nice if you could do what you want to do but you can't.
For clarity lets denote operator[] by F, and operator= by G, then
essentially what you are asking for is the compiler to distinguish between
calls to F in
G(...,F(i))
from
G(F(i), ...)
But the compiler cannot do this for any normal function so there is no
reason to expect it to work for operator[] and operator=.
> 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.
Right, which is why you should avoid operator[] on reference counted string
classes. It is impossible to implement in an efficient manner. Implementing
operator[] on a non-const reference counted string class means a compromise,
either you have to take a copy of the string immediately even though
operator[] might only be being used to read from the string, or you have to
write a proxy class (e.g. Cref in Stroustrup).
>
> 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.
Well there is no RHS version of [] you have been misinformed. If you omitted
the const version of operator[] from Stroustrup's code then the following
would not compile
const String x = "abc";
cout << x[0];
This is the true meaning of the const version of operator[], it allows you
to access const objects. Same as any other const method.
john
John Harrison
> 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.
>
BTW, from the above site
"When an STL string object is assigned to another string object, a copy is
made. In contrast, the String container copies a reference and increments a
reference count."
This is not strictly correct, the standard leaves it up to the
implementation whether to use reference counting or not. My version of the
STL (dinkumware) does use reference counting.
john
Thomas Mang
"(null)" schrieb:
> class MyClass
> {
> //...
> // in theory, the RHS operator
> const int operator[](const int i ) const;
> // in theory, the LHS operator
> int& operator[](const int i );
> //...
> }
All these members are in the private section of the class.
I assume you missed a "public:" somewhere.
>
>
> 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.
No surprise at all.
Your foo-object is non-const, so the compiler invokes the non-const
overloaded operator[].
Why should it invoke the const version?
Things are totally different when foo is defined as const:
const MyClass foo;
Then the compiler will, of course, invoke the const-version of operator[].
Note that this overload resolution has nothing to do with the fact if you
use your overloaded operator[] at the call site as LHS or RHS.
regards,
Thomas
Joshua Lehrer
> Right, which is why you should avoid operator[] on reference counted string
> classes. It is impossible to implement in an efficient manner. Implementing
> operator[] on a non-const reference counted string class means a compromise,
> either you have to take a copy of the string immediately even though
> operator[] might only be being used to read from the string, or you have to
> write a proxy class (e.g. Cref in Stroustrup).
You seem to be making an assumption here. If I read your statement
correctly, you say that it is impossible to implement the non-const
index operator on a reference counted String in an efficient manner.
You then state that in order to do this, you need to write a proxy
class. Therefore, you are making the assumption that the proxy class
makes the class non-efficient.
This *may* not be true. It depends on if the compiler can optimize
away much, if not all, of the use of the proxy class.
Even if this one function makes the refernce counted String class
slightly less efficient to use, the other gains from the
refernce-counted String class *may* outweigh this small expense- it
proveably did on our system. The only way to tell on your system is
to try it.
We have a home grown reference counted String class, and it uses a
proxy class to implement the return value of the non-const index
operator. The class is extremely efficient, and fast. Our source
code base which uses this class has about 400 engineering-man-years of
development in it, consisting of hundreds of thousands of lines of
code. When we released our reference counted String class in place of
the old version, we saw at least a 10% improvement in our average CPU
consumption. Sections of our application which used Strings heavily
saw much more significant gains. We are certain that we would see
even more gains if we did not have legacy code that depended on
certain behaviors of the old String class, which required some slight
inefficiencies be purposely introduced into the new String class.
The bottom line- lots of reference-counted string bashing goes on in
this newsgroup. Most of this bashing is by people who probably never
wrote such a class themselves. We took the time to write one, and
thoroughly test and review it for completeness, correctness, and
safety. This class has had nothing but positive impact on *our*
system. Your mileage may vary.
joshua lehrer
factset research systems
NYSE:FDS
p.s. to order your very own "RefStrings Rule!" bumper-sticker, send a
self addressed stamped envelope to...
John Harrison
"Joshua Lehrer" <usene...@lehrerfamily.com> wrote in message
news:31c49f0d.03071...@posting.google.com...
> "John Harrison" <john_an...@hotmail.com> wrote in message
news:<berg4s$892s3$1...@ID-196037.news.uni-berlin.de>...
>
> > Right, which is why you should avoid operator[] on reference counted
string
> > classes. It is impossible to implement in an efficient manner.
Implementing
> > operator[] on a non-const reference counted string class means a
compromise,
> > either you have to take a copy of the string immediately even though
> > operator[] might only be being used to read from the string, or you have
to
> > write a proxy class (e.g. Cref in Stroustrup).
>
>
> You seem to be making an assumption here. If I read your statement
> correctly, you say that it is impossible to implement the non-const
> index operator on a reference counted String in an efficient manner.
> You then state that in order to do this, you need to write a proxy
> class. Therefore, you are making the assumption that the proxy class
> makes the class non-efficient.
OK, maybe I didn't choose the best words. Substitute 'as simply as you
think' for 'efficiently'.
>
> This *may* not be true. It depends on if the compiler can optimize
> away much, if not all, of the use of the proxy class.
>
> Even if this one function makes the refernce counted String class
> slightly less efficient to use, the other gains from the
> refernce-counted String class *may* outweigh this small expense- it
> proveably did on our system. The only way to tell on your system is
> to try it.
Couldn't disagree with that.
>
> We have a home grown reference counted String class, and it uses a
> proxy class to implement the return value of the non-const index
> operator. The class is extremely efficient, and fast. Our source
> code base which uses this class has about 400 engineering-man-years of
> development in it, consisting of hundreds of thousands of lines of
> code. When we released our reference counted String class in place of
> the old version, we saw at least a 10% improvement in our average CPU
> consumption. Sections of our application which used Strings heavily
> saw much more significant gains. We are certain that we would see
> even more gains if we did not have legacy code that depended on
> certain behaviors of the old String class, which required some slight
> inefficiencies be purposely introduced into the new String class.
>
> The bottom line- lots of reference-counted string bashing goes on in
> this newsgroup.
Not by me (at least not intentionally). Hell, I even believe that copy on
write is a generally useful technique.
> Most of this bashing is by people who probably never
> wrote such a class themselves. We took the time to write one, and
> thoroughly test and review it for completeness, correctness, and
> safety. This class has had nothing but positive impact on *our*
> system. Your mileage may vary.
>
> joshua lehrer
> factset research systems
> NYSE:FDS
>
> p.s. to order your very own "RefStrings Rule!" bumper-sticker, send a
> self addressed stamped envelope to...
Where? Where can I get one!?
john
James Kanze
|> 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 );
|> //...
|> }
That's correct. The first could also return an int const&.
|> 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.
Overloading is determined uniquely by the types in the
(sub-)expression, and not by context. (There are one or two minor
exceptions, but they don't apply here.) If you call [] on a const
object, you get the const function. If you call it on a non-const
object, you get the non-const form.
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.:
class MyClass
{
public:
class Proxy
{
friend class MyClass ;
public:
operator int() const
{
return myOwner.get( myIndex ) ;
}
Proxy const& operator=( int other ) const
{
myOwner.put( myIndex, other ) ;
return *this ;
}
private:
Proxy( MyClass& owner, int index )
: myOwner( owner )
, myIndex( index )
{
}
MyClass& myOwner ;
int myIndex ;
} ;
void put( int index, int newValue ) ;
int get( int index ) const ;
Proxy operator[]( int index )
{
return Proxy( *this, index ) ;
}
int operator[]( int index ) const
{
return get( index ) ;
}
} ;
All of the actual logic is then in get and put.
--
James Kanze mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Bo Persson
"(null)" <ia...@idiom.com> skrev i meddelandet
news:1058054598.920916@smirk...
> I have not posted to comp.lang.c++ (or comp.lang.c++.moderated)
> 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
The const version of the operator is invoked when foo is const or a
const reference. There is really no other way to know if you intend to
modify it.
What if you do
int& i = foo[j];
//...
i = 42;
> 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.
This is one of the reasons why reference counted string classes are
not that popular any more.
>
> 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.
Except that in your case you cannot return an int& when *this is
const. That would require a const_cast instead.
>
> 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.
So would many of us.
Bo Persson
bo...@telia.com
Francis Glassborow
> 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 );
> //...
> }
because of your comments but the compiler only sees the source code. If
you index a non-const variable it will call the non-const version, if
you index a const variable it will call the const version.
That is why we write proxies to handle the non-const version that
provide for assignment as well as getting the value. The non-const
version of MyClass::operator[]needs to return a MyClass::ref which
supports an operator int()to provide the value and an operator= to deal
with the assignment.
Here is an example of a slightly more complicated case from some of my
code (with only the relevant material quoted):
class hue{
public:
bool operator[](int bit)const {
if(bit <0 or bit >7) return false;
return bitset<8>(code_)[bit];
}
class ref;
friend class hue::ref;
class ref{
public:
ref(hue & h, int n):h_(h),bit(n){};
operator bool(){
if (bit <0 or bit >7) return false;
return bitset<8>(h_)[bit];
}
void operator=(bool val){
if(bit <0 or bit >7) return;
bitset<8> v(h_);
v[bit] = val;
h_ = (unsigned char)v.to_ulong();
}
private:
hue & h_;
int bit;
};
ref operator[](int bit){return ref(*this, bit);}
private:
unsigned char code_;
};
--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU
llewelly
> I have not posted to comp.lang.c++ (or comp.lang.c++.moderated)
> 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).
Well it is a big book sometimes people miss things, or don't add up
seperate things in the intended way. 10.2.6 explains constant
member functions.
>
> 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 );
'const' is a propertery of an object, not of an operator=. If the
instance of MyClass is const, the first will be called, and if the
instance of MyClass is not const, the second will be called. This
is true regardless of which side of operator= the use of
operator[] occurs.
(Note: in order to have behavior more like that of builtin[], the
first operator[] should return 'int const&' )
> //...
> }
>
> 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.
[snip]
This is correct behavior; foo is not const, so
int& MyClass::operator[](int) is called, and not
int const MyClass::operator[](int) const . It is constness,
and not side of operator=, that matters. Had you written:
MyClass const foo;
int i = foo[j];
foo[j]= i;
both calls would have called
int const MyClass::operator[](int) const .
Siemel Naran
> class MyClass
> {
> const int operator[](const int i ) const;
> int& operator[](const int i );
> }
For a non-const MyClass, the non-const operator[] is always called, even if
the return is used as an lvalue! There are two options.
(1) Make your MyClass object const, or in functions receive it by reference
to const or const value. But it does seem inelegant.
template <class T> inline const T& to_const(T& t) { return t; }
int i = to_const(foo)[j]; // RHS reference NOT!
(2) Make the non-const operator[] return a class. This class will have an
operator int() const that returns a plain integer if the class is used as an
lvalue, and when used as an rvalue does something else. But it is clunky.
class MyClass {
public:
class Reference;
const int operator[](int i ) const;
Reference operator[](int i );
protected:
friend class Reference;
void alter();
private:
int d_integer;
};
class MyClass::Reference {
public:
operator const int() const { return d_value; }
int& operator=(const int newvalue) {
d_envelope.alter();
d_value = newvalue;
return d_value;
}
/* may need to replicate interface of class int -- uuurghhhh */
protected:
friend class MyClass;
Reference(MyClass& envelope, int& value);
private:
MyClass& d_envelope;
int& d_value;
};
const int MyClass::operator[](const int i) const {
return d_integer;
}
MyClass::Reference MyClass::operator[](const int i) {
return Reference(*this, d_integer);
}
(2b) It's clunky because you have to replicate the interface of class int in
class Reference. Have to write operator+= and hundreds of other functions.
(Ok, literally about 20, but it could be 100 for your own class.) Maybe
then you can give you class Reference just one function -- namely alter() as
a public function which calls the envelope's alter()
class MyClass::Reference {
public:
operator const int() const { return d_value; }
int& alter() { d_envelope.alter(); return d_value; }
protected:
friend class MyClass;
Reference(MyClass& envelope, int& value);
private:
MyClass& d_envelope;
int& d_value;
};
It seems more elegant than (1), and not as clunky as (2), but still a little
clunky :)
--
+++++++++++
Siemel Naran
ka...@gabi-soft.fr
news:<31c49f0d.03071...@posting.google.com>...
[...]
> The bottom line- lots of reference-counted string bashing goes on in
> this newsgroup. Most of this bashing is by people who probably never
> wrote such a class themselves. We took the time to write one, and
> thoroughly test and review it for completeness, correctness, and
> safety. This class has had nothing but positive impact on *our*
> system. Your mileage may vary.
I suspect that most of the bashing is an accidental extension of
reference-count bashing with regards to an implementation of
std::string. The standard does NOT allow the use of a proxy -- the
non-const version of operator[] must return a real reference. This
requires special handling even in a single threaded version with
reference counting, and is almost impossible to get right efficiently in
a multi-threaded version -- you end up needing a lock for practically
every single access.
For the rest, in the past, I too have found reference counting to be a
win. In my own code -- I can't speak for others. (Like you, my string
class used a proxy as the return value for the non-const operator[].)
--
James Kanze GABI Software mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Carl Barron
const int rhs_bracket(i) const
{
// perform = overloaded_array[i]
printf("RHS a[%2d]\n",i);
return pArray[i[;
}
void lhs_bracket(int i,int x)
{
// perform overloaded_array[i] = x;
printf("LHS a[%2d] = %d\n",i,x);
pArray[i] = x;
}
> public:
class proxy
{
overloaed *over;
int index;
proxy(overloaded *a,int b):over(a),index(b){}
public:
friend class overloaded;
operator int() { return over->rhs_bracket(i);}
proxy & operator = (int x)
{
over->lhs_bracket(i,x);
return *this;
}
};
friend class proxy;
proxy operator [] (int i) {return proxy(this,i);}
> overloaded( size_t size )
> {
> pArray = new int[ size ];
> }
>
> ~overloaded()
> {
> delete [] pArray;
> }
>
#if 0
> // 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];
> }
#endif
> }; // overloaded
> ...
This will result in different behavior depending on whether operator
[] is used to read or write data to/from an overloaded.
Note i used mutual friendship so only overloaded::operator [] will
create an overloaded::proxy objwct. and private functions to do the
different items on the lhs and rhs of an equal sign. Making them private
and proxy a friend means that only proxy is going to access these
implimentation detail functions. This approach can also be used with
operator *() and operator ->() to preform different operations when
reading and writing.
Thomas Mang
James Kanze schrieb:
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)
regards,
Thomas
Glen Low
> 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.
What you need is to return a proxy class that overloads operator= and
operator int. Roughly:
class MyClass
{
public:
int operator[] (int i) const; // RHS
int_proxy operator[] (int i) { return int_proxy (p_ + i); }
private:
int *p_;
};
class int_proxy
{
public:
int_proxy& operator= (int val) { *r_ = val; }
operator int () const; // RHS
int_proxy (int* r): r_ (r) { }
private:
int *r_;
};
Essentially the int_proxy acts like a int&, but whatever special code
you would have put in the RHS function in the original, you put that
same code in the RHS function in the proxy. (Stylistically, you could
use templates and put int_proxy inside of MyClass.) I believe
std::vector<bool> is specialized to do this.
Now when you call a [i], you get a temporary proxy. If there is an
access, then operator int gets called with your special RHS code; if
there is a mutate, then operator= gets called.
If it's all inline and optimizations are on, chances are the compiler
will optimize away the temporary int_proxy object. The only drawback I
can see is that the return type is no longer int&, which may crap out
code that expects it e.g. int& ri = a [i].
P.S. If you're irritated by having to repeat RHS code twice, either
cause the int_proxy version to call the MyClass version, or return a
const int_proxy from the MyClass RHS function.
Rob
>
> 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.
>
This is actually the way it's supposed to be. foo is not a const object,
so when
there is a choice (as in this case) the non-const version of the operator
should
be invoked.
Siemel Naran
> class hue{
> public:
> bool operator[](int bit)const {
> if(bit <0 or bit >7) return false;
> return bitset<8>(code_)[bit];
> }
> class ref;
> friend class hue::ref;
> class ref{
> public:
> ref(hue & h, int n):h_(h),bit(n){};
> operator bool(){
> if (bit <0 or bit >7) return false;
> return bitset<8>(h_)[bit];
> }
> void operator=(bool val){
> if(bit <0 or bit >7) return;
> bitset<8> v(h_);
> v[bit] = val;
> h_ = (unsigned char)v.to_ulong();
> }
> private:
> hue & h_;
> int bit;
> };
> ref operator[](int bit){return ref(*this, bit);}
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?
--
+++++++++++
Siemel Naran
Glen Low
>
> int& operator[](int index)
An int& is dumb, it cannot distinguish whether it is being written to
or read. A proxy object is smart, it knows when it is written (via
operator=) or read (via operator int), and can execute different code
as a result.
Francis Glassborow
Siemel Naran <Sieme...@REMOVE.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.
--
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 ]
Siemel Naran
> >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.
--
+++++++++++
Siemel Naran
Francis Glassborow
Siemel Naran <Sieme...@REMOVE.att.net> writes
>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.
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.
--
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 ]
Andrey Tarasevich
> ...
> 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.
> 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.
--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP
Andrey Tarasevich
> ...
> 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.
> 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.
--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP
Glen Low
> 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.
At the cost of some minor ickiness you could:
1. Make the proxy overload operator*, operator-> and operator->*
(can't remember whether you can overload operator.*). So you could do
something like env["abc"]->memfun ();
2. For consistency, you could have operator= take a T*.
3. Entirely different track: both the proxy and the object could
inherit from some base class, using the "curiously recursive" pattern
to avoid virtual functions.
ka...@gabi-soft.fr
news:<6XASa.63966$0v4.4...@bgtnsc04-news.ops.worldnet.att.net>...
> "Francis Glassborow" <francis.g...@ntlworld.com> wrote in message
> > Siemel Naran <Sieme...@REMOVE.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...@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
ka...@gabi-soft.fr
news:<3F165D0A...@unet.univie.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::operator[] 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...@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Francis Glassborow
<andreyta...@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 ]
Daniel Spangenberg
Andrey Tarasevich schrieb:
> 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.
And not to forget: Even if the member function returns a reference, it can
do much more additionally, like
- Counting the number of accesses
- Perform any logging facilities
and so on. But you are lost, if you want manually perform the same task
externally
and reliably with direct access to the data.
Daniel
llewelly
> 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<iostream>
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.foo(), &b, &b + 1) == "
<< is_within(&b.foo(), &b, &b + 1) << std::endl;
}
I believe the expression 'is_within(&b.foo(), &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.
Siemel Naran
> "Siemel Naran" <Sieme...@REMOVE.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::Reference {
public:
void constmemfun() const {
return d_object.constmemfun();
}
void memfun() const {
d_envelope.alter();
return d_object.memfun();
}
private:
Envelope& d_envelope;
Envelope::Object& d_object;
};
--
+++++++++++
Siemel Naran
ka...@gabi-soft.fr
>>> 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::Reference {
> public:
> void constmemfun() const {
> return d_object.constmemfun();
> }
> void memfun() const {
> d_envelope.alter();
> return d_object.memfun();
> }
> private:
> Envelope& d_envelope;
> Envelope::Object& 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...@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Andrey Tarasevich
> >
> > 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<iostream>
>
> 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.foo(), &b, &b + 1) == "
> << is_within(&b.foo(), &b, &b + 1) << std::endl;
> }
>
> I believe the expression 'is_within(&b.foo(), &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
llewelly
[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.
Glen Low
> 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/
Maciej Sobczak
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/
Joshua Lehrer
news:<bgnpjb$qog$1...@nemesis.news.tpi.pl>...
> 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.
But where did you "use" that reference? The constructor first
initializes "reference" to refer to the memory location where "y_"
will be stored. Then, before anyone uses "reference", the memory at
the location where "y_" is to be stored is initalized by calling "Y"'s
default constructor. Now "y_" is the name of a location holding a
"Y", and "reference" refers to that same location.
Had you used "reference" between the time that it was initialized to
point to the same memory as "y_", and the time that "y_" was
initialized, then you would have a problem. However, without reading
the standard, I'm not convinced that the above should be illegal. Bad
form? Yes.
joshua lehrer
factset research systems
NYSE:FDS
Daniel Spangenberg
Maciej Sobczak schrieb:
[snip]
> 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.
My interpretation of what is written in 3.7.3.1/p. 2 and in 3.8/p. 5 let me
deduce, that your example should be well-defined.
Greetings,
Daniel