This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/31652] postfix increment semantics implemented incorrectly



------- Comment #4 from pinskia at gcc dot gnu dot org  2007-04-22 07:03 -------
> 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.

Why do you say could blow the stack, the C++ standard actually mentions an
optimization where the copy constructored is removed and there is no extra
variable.  It is called named return value optimization which removes the need
for the extra stack, basically the return value is actually a pointer that is
passed into the function and then initialized that way.

So I don't see your point still.

The result you are seeing is exactly, I mean exactly what the C++ standard says
the results should be as b = a++; is translated exactly as b = a.operator++(0);
and not as b = (tmp = a, a.operator++(0), tmp);  In fact this is worse than
what you are suggesting the C++ standard says there is an extra tmp variable on
the stack to begin with while before with named return value, you don't have
one.


>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.

Actually it would violate the C++ standard and break existing code as people
don't have to return the copy.  Your example shows exactly why your proposal
change will break valid code.

I think you need to go back and read more about overloading operators as it
seems like you don't understand that overloading operators can sometimes change
the semantics if the overloaded operator changes them as shown by your example.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31652


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]