Re: Sequence point problem?

From: Victor Bazarov (v.Abazarov_at_comAcast.net)
Date: 02/05/05 

Date: Sat, 5 Feb 2005 15:31:49 -0500

"Dave" <better_cs_now@yahoo.com> wrote...
> Can anybody identify any sequence point problems in the expression below?
>
> i = (i == string::npos) ? 0 : ++i;

The Standard says that between sequence points (and there are none in
this expression) a stored value of any object shall be modified at most
once. If the expression in the parentheses yields false, 'i' will be
modified twice, once by ++ and the other time with the assignment, which
causes undefined behaviour. If you rewrite this as

   i = (i == string::npos) ? 0 : i + 1;

there would be no problem.

V

Relevant Pages

  • Re: pre, post increment standard behaviour, and friend function declaration
    ... > There is nothing in the standard that prevents an implementation from ... modified twice between sequence point for ANY ALLOWABLE ORDERING ...
    (comp.lang.cpp)
  • Re: question about printf
    ... >> but that a is modified twice, and read one extra time, between adjacent ... >> sequence points, causing undefined, not just unspecified, behaviour. ... of which once not for the reason of computing the modified value. ...
    (comp.lang.c)
  • Re: order of evaluation
    ... > The compiler is allowed to determine the order in which the 4 calls ... but it may not execute them concurrently (unless you cannot detect ... the only thing unspecified is the order of sequence points. ... No variable is modified twice between sequence points. ...
    (comp.lang.cpp)
  • Re: Is i = i++; bad style?
    ... "Between the previous and next sequence point an object shall have its ... Assignment does not introduce a sequence point so i is modified twice ... constraint causes undefined behavior. ...
    (comp.lang.c)
  • Re: "Variables" tutorial available (Windows, mingw/msvc)
    ... >>I'm afraid it is undefined behaviour, since x is modified twice without ... >>about unspecified order of evaluation. ... > constraint (sequence point) for the expression in which it appears. ... Therefore my example can _never_ invoke ...
    (comp.lang.cpp)