I have been chewing on this for a few months now, including in this
group, and not seeing any consensus.  I would like some feedback about
whether a DR on some wording changes to the standard (not changes to
the language) seems advisable to others beside me.

Is the behavior of the following defined or undefined?

#include <iostream>
int main(void)
{
   int x = 0;
   (x = 2) = 3;
   std::cout << "x is " << x << std::endl;
   return 0;
}

Does your opinion change if x is defined volatile?

Can a conforming program output anything other than 3?

Given this wording of the standard in paragraph 1 of 5.17:

       There are several assignment operators, all of which group
       right-to-left. All require a modifiable lvalue as their left
       operand, and the type of an assignment expression is that of
       its left operand. The result of the assignment operation is the
       value stored in the left operand after the assignment has taken
       place; the result is an lvalue.

Since the phrase "after the assignment has taken place" imposes a
sequence of actions on the generated code, should it be defined as a
sequence point?  Why or why not?

Is the wording of this paragraph ambiguous and/or confusing?  I
realize that it was most likely based on editing the wording from C90,
which contained the phrase "but it is not an lvalue", but would it be
better to merely say that the result is the object itself after the
assignment has taken place?

Given this slightly different wording in paragraph 1 of 5.3.2:

       The operand of prefix ++ is modified by adding 1, or set to
       true if it is bool (this use is deprecated). The operand shall
       be a modifiable lvalue. The type of the operand shall be an
       arithmetic type or a pointer to a completely-defined object
       type. The value is the new value of the operand; it is an
       lvalue. If x is not of type bool, the expression ++x is
       equivalent to x+=1.

Is there a reason for the omission of wording such as "after the
increment has taken place" similar to that in 5.17?

Personally I think that the assignment operators and pre increment and
decrement operators should be added to the list of defined sequence
points in 1.9, which will make the matter much clearer.

I am actually concerned with the decision to make the results of these
operators lvalues as opposed to rvalues as they are in C.  I know that
the reason is to make their use on built-in scalar types more
consistent with the usual and customary form of the same operators
overloaded for user defined types.  I am also aware that this has been
in the language since the ARM (at least the 1990 version that I own)
and will not be changed.

My primary concern is that this language feature can cause some quiet
changes with serious consequences when volatile objects that are
actually mapped to hardware appear in certain expressions with these
operators.  If the value of a subexpression using these operators on a
volatile object is used further in a statement, the rules of lvalue to
rvalue conversion require that the program read the new value back
from the volatile object after storing it.  Code that worked properly
compiled as C can suddenly stop working if compiled as C++ for no
obvious reason at all.

When I have mentioned these possible consequences when dealing with
volatile objects in the past, a few replies have included comments to
the effect that relatively few programmers deal with such issues.
That is true, but C++ fiercely maintains its appropriateness as a
system programming language as useful as C, and I am one of those few
programmers who writes such code for a living.

Again I am not seeking to change the language, just the wording of the
standard to make these differences from C more prominent.  In addition
to the possibility of adding these operators to the list of those
which create sequence points, I would welcome suggestions for any
other wording changes or additions to the standard that would make the
possible consequence of using these operators incautiously with
volatile objects more obvious.

TIA for all input.

--
Jack Klein
Home: http://JK-Technology.Com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Jack Klein <jackklein@spamcop.net> wrote:
: I have been chewing on this for a few months now, including in this
: group, and not seeing any consensus.  I would like some feedback about
: whether a DR on some wording changes to the standard (not changes to
: the language) seems advisable to others beside me.

: Is the behavior of the following defined or undefined?

: #include <iostream>
: int main(void)
: {
:    int x = 0;
:    (x = 2) = 3;
:    std::cout << "x is " << x << std::endl;
:    return 0;
: }

: Does your opinion change if x is defined volatile?

: Can a conforming program output anything other than 3?

: Given this wording of the standard in paragraph 1 of 5.17:

:        There are several assignment operators, all of which group
:        right-to-left. All require a modifiable lvalue as their left
:        operand, and the type of an assignment expression is that of
:        its left operand. The result of the assignment operation is the
:        value stored in the left operand after the assignment has taken
:        place; the result is an lvalue.

: Since the phrase "after the assignment has taken place" imposes a
: sequence of actions on the generated code, should it be defined as a
: sequence point?  Why or why not?

IIRC, this exact topic was discussed at length about a year ago,
either in this group or comp.std.c++.  I'm of the opinion that:

  (1) The final sentence quoted above is an oxymoron.  (Taken
      literally, it says that an lvalue is stored in the left operand.)

  (2) In (x=2)=3, the variable x gets modified twce between adjacent
      sequence points, thereby, invoking undefined behavior.

Tom Payne












---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]