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

["hayward at loup dot net" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #5 from hayward at loup dot net  2007-04-22 16:37 -------
Subject: Re:  postfix increment semantics implemented incorrectly

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

An optimizing compiler could, in theory, optimize out copy
construction and only copy the object portions modified in the body of
the postfix operator.  In practice that increment body could be far
more complex than simply incrementing a 32 bit counter and the return
value could be also be used for arbitrarily complex manipulations.  In
these cases the current interpretation will by necessity involve a
complete copy.

Consider a trivial example of a large n dimensional matrix object
where calling postfix increment should increment every component in
the entire matrix.  Assuming the matrix is actually used in the
expression, there is no inexpensive way to perform the postfix
increment without post evaluating the method.

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

It appears you are not completely undestanding my suggestion.  There
exists a difference between postfix syntax and postfix semantics.  I
am not by any means saying that a++ would not be equivalent to
a.operator++(0) as the operator notation is simply syntactic sugar.  I
am suggesting that they of course have equivalent semantics as is
specified, but that the semantics would be different from prefix ++a
and a.operator++().  If the operator doesn't has postfix semantics, it
is both misleading and additional syntax of limited use.

No expensive temporary copies need be involved as in the return by
value example you give... that would defeat the return by reference
argument I'm making.  Implementation would simply involve creating a
subsequent sequence point for any and all post rvalue operations.  For
example:

b = a++;               // postfix operator syntax

b = a;                 // equivalent semantics without postfix operator
++a;

Or if you prefer method syntax:

b = a.operator++(0);   // postfix method syntax

b = a;                 // equivalent semantics without postfix method
a.operator++();

 > 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 realize a change could break code that depends on the current
implementation and doesn't return a copy by value.  Maybe that's
reason enough to not change an implementation, but I think not.  I'm
making the case that the implementation does not implement the intent
of the C++ standard.  There is the "letter of the law" and the "spirit
of the law" and without a more explicit specification, it is
understandable how we could argue for either interpretation.  That is
why if there is ambiguity I gravitated to the expected, semantically
consistent, more efficient, and simpler case.

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

The semantics of an expression are dependent upon the method
implementation, of course, but also upon order of operation which
includes operator associativity.  It was my understanding that order
of operation and associativity are the same regardless of basic or
overloaded operator status.  The whole notion of postfix operation is
pretty simple to grasp (that the operation is performed "after" it is
used in the expression) and it's disappointing that although it could
be very efficient for arbitrary objects, it simply is not as it is
implemented now.

Since I am now clear that it is implemented as you would intend, I
will hold peace if you do not wish to champion my interpretation.  I
at least want someone in a position to affect things to fully grasp
the point I am making.  Perhaps yours is the more widely adopted
interpretation of the spec as written, but surely you see the benefit
of post expression semantics?  I think it would be useful if someone
could get the specification clarified and annotated on this point...

Once again, thanks for the feedback, and cheers :-)

- Mike


-- 


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