[comp.lang.c++.moderated] Re: operator= return ref or const ref?
Andrew Koenig
heard> behave that way? How can the standard library (or anything
heard> else) actually _use_ the non-const reference returned from an
heard> assignment to a variable of builtin type in a way that exploits
heard> its non-constness, without causing undefined behaviour due to
heard> multiple stores without an intervening sequence point?
The original reason for making builtin types behave that way was so that
x = y;
return x;
and
return x = y;
would have the same meaning, even inside the body of a function
that returns a reference.
Incidentally, I believe that the rule that renders
(a = b) = c;
undefined to be a mistake and would like to see it changed in a
future revision of the standard. This particular example is silly,
but the following one is much less so:
(x[i++] *= p) += q;
Of course it is possible to write
x[i] *= p;
x[i++] += q;
instead, but I find the first form significantly easier to understand.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Andrew Koenig
Francis> <a...@research.att.com> writes
>> Incidentally, I believe that the rule that renders
>> (a = b) = c;
>> undefined to be a mistake and would like to see it changed in a
>> future revision of the standard.
Francis> By adding sequence points in assignment operators? I think that will
Francis> need a little care.
I agree it will need a little care. What I'd like to see is
a requirement for an implementation to complete evaluation of
the operands of a built-in operator (except for operands that
are conditionally evaluated, and delayed side effects such as
postfix ++ and --) before evaluating the operator itself.
Andrew Koenig
Hendrik> of a non-const reference as an assignment result?
What it gains is removing a real pitfall that bit a real programmer.
What are the disadvantages of a non-const reference as an
assignment result, aside from prohibiting some programs
that some people personally dislike?
>> [...] This particular example is silly,
>> but the following one is much less so:
>> (x[i++] *= p) += q;
>> Of course it is possible to write
>> x[i] *= p;
>> x[i++] += q;
>> instead, but I find the first form significantly easier to understand.
Hendrik> I actually had to read that trice to make sure I'm not
Hendrik> getting you wrong. (I'm a German.) You must be joking.
Not at all.
Hendrik> I had a few hours since I read it and mailed about a
Hendrik> dozen people. Three of them actually simply said they
Hendrik> disagree. All the rest said something about slaughtering
Hendrik> any fellow worker who would argue this way. Or other nasty
Hendrik> things.
Hendrik> Maybe I know the wrong people.
It sure sounds like it.
{please see the invisible emoticon :) -mod/fwg}
One thing about C++ is that there is a very wide spectrum of styles
amongs its users.
Andrew Koenig
Hendrik> Wait a minute...
Hendrik> _What_ did nite a real programmer?
Once upon a time, someone I know personally wrote
return *this = new_value;
and thought it would have the same effect as if he had written
*this = new_value;
return *this;
Unfortunately, it didn't, because the code was inside a member function
that happened to return a non-const reference to the type of its object.
The equivalence between
return x = y;
and
x = y;
return x;
exists in C, so it is natural to assume that it also exists in C++.
In order to maintain that equivalence in C++, it is necessary for
built-in = to return a nonconst reference to the left-hand side.
This event was the impetus for making = return a reference instead
of an rvalue in C++.
>> One thing about C++ is that there is a very wide spectrum of styles
>> amongs its users.
Hendrik> Right. Let's not get entangled in style, when actually
Hendrik> we're discussing syntax.
I think we're discussing style. That is, I think we're discussing
which usages we personally like and dislike, and how much support
we would like to see in the language for enforcing our taste on
other people.