------- Comment #3 from hayward at loup dot net 2007-04-22 06:40 -------
Subject: Re: postfix increment semantics implemented incorrectly
Thanks for the quick response. I do not, however, agree with this
interpretation of ISO/IEC FDIS 14882:1998(E) 13.5.7/1.
The spec trivially exemplifies the equivalance of the method syntax
and the postfix operator, but it mentions no explicit deviation from
post rvalue execution semantics. Although it doesn't give a return by
reference example, nor does it provide a return by value definition in
it's example. The spec does not mention anything about the postfix
increment and decrement methods being limited to providing post op
semantics for return by value and only if a copy constructor is
explicitly invoked at that.
Using a copy constructor and returning by value is of limited
applicability. Having to invoke a copy constructor to "simulate" a
post rvalue operation is not an option for objects that do not support
copy, and perhaps more significantly for large objects, is both very
time inefficient and could blow stack.
I'm certain the language designers are aware of return by reference as
well as the costs and limitations of copy constructors and expect they
would be explicit if they intended this behavior. Perhaps I am wrong,
but I have a hard time imagining this is what anyone involved with
this later language feature was trying to achieve.
Regardless of my speculation, *please consider* that changing the GNU
implementation to invoke the method after it is evaluated as an rvalue
would not in any way violate the specification or example of 13.5.7/1
and would make the method both intuitive and capable of working as
expected for return by reference. Furthermore, changing the
implementation would not break any existing code that returns a copy
constructed object as in your example. Such a change could only alter
semantics of source code that depends on non post rvalue op semantics
which are certainly not expected, specified, or likely.
Cheers.
- Mike
> ------- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-21 23:49
-------
> This is not a bug in GCC but instead a bug in your post fix increment
operator:
> C & operator++( int ) { v += 100; return *this; }
>
> Really should be implemented as:
> C operator++( int ) { C tmp = *this; v += 100; return tmp; }
>
> Which is the correct way of implementing it. postfix increment returns a
> rvalue and not a lvalue. See example in the C++ standard in 13.5.7/1.
> Basically you just changed the semantics of post fix increment with the
> operator overloader and changed it to be about the same as the pre
incrementor
> except incrementing by 100 instead of by 1.
>
> Again this is not a bug in GCC but instead a bug in your code.
>
> b = a++; is the same as doing:
> b = a.operator++(0);
>
> So if your operator++(int) returns *this, the result you are seeing is
exactly
> what is expected from the C++ standards point of view.
>
>
> --
>
> pinskia at gcc dot gnu dot org changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|UNCONFIRMED |RESOLVED
> Resolution| |INVALID
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31652
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31652
