«

Is there any reason why the following C++ code behaves as it does ?



int i;

i=1; cout << (++i)++; Output: 2

i=1; cout << ++(++i); Output: 3

i=1; cout << (i++)++; Output: Error. LValue required

i=1; cout << ++(i++); Output: Error. LValue required

bintom wrote:
> Is there any reason why the following C++ code behaves as it does ?
>
>
>
> int i;
>
> i=1; cout << (++i)++; Output: 2
>
Because it's nonsensical undefined behaviour.

--
Ian Collins.

Victor Bazarov wrote:
> Ian Collins wrote:
>> bintom wrote:
>>> Is there any reason why the following C++ code behaves as it does ?
>>>
>>>
>>>
>>> int i;
>>>
>>> i=1; cout << (++i)++; Output: 2
>>>
>> Because it's nonsensical undefined behaviour.
>
> Why is it non-sensical? Why is it undefined?
>
You are right, it is neither. Sorry, I've seen way too many posts that
are and do...

--
Ian Collins.

Hi Jack,

Thank for your inputs on undefined/invalid uses (rather than
unpredictable results) of ++ operator. It was a great help.

bintom

On May 9, 2:54 am, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
> Ian Collins wrote:
> > bintom wrote:
> >> Is there any reason why the following C++ code behaves as it does ?

> >> int i;

> >> i=1; cout << (++i)++; Output: 2

> > Because it's nonsensical undefined behaviour.

> Why is it non-sensical? Why is it undefined?

Because the standard says so. You're modifying the same object
twice without an intervening sequence point.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze dixit:
> On May 9, 2:54 am, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
>> Ian Collins wrote:
>>> bintom wrote:
>>>> Is there any reason why the following C++ code behaves as it does ?
>
>>>> int i;
>
>>>> i=1; cout << (++i)++; Output: 2
>
>>> Because it's nonsensical undefined behaviour.
>
>> Why is it non-sensical? Why is it undefined?
>
> Because the standard says so. You're modifying the same object
> twice without an intervening sequence point.

Can you tell what is an intervening sequence point ?

Thanks

Ian Collins wrote:
> Victor Bazarov wrote:
>> Ian Collins wrote:
>>> bintom wrote:
>>>> Is there any reason why the following C++ code behaves as it does ?
>>>>
>>>>
>>>>
>>>> int i;
>>>>
>>>> i=1; cout << (++i)++; Output: 2
>>>>
>>> Because it's nonsensical undefined behaviour.
>> Why is it non-sensical? Why is it undefined?
>>
> You are right, it is neither. Sorry, I've seen way too many posts that
> are and do...
>
Um, undefined behaviour overload. I was right the first time...

--
Ian Collins.

brno wrote:
> James Kanze dixit:
>> On May 9, 2:54 am, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
>>> Ian Collins wrote:
>>>> bintom wrote:
>>>>> Is there any reason why the following C++ code behaves as it does ?
>>
>>>>> int i;
>>
>>>>> i=1; cout << (++i)++; Output: 2
>>
>>>> Because it's nonsensical undefined behaviour.
>>
>>> Why is it non-sensical? Why is it undefined?
>>
>> Because the standard says so. You're modifying the same object
>> twice without an intervening sequence point.
>
> Can you tell what is an intervening sequence point ?
>
A sequence point occurs after the evaluation of a full expression.
"(++i)++;" is an expression with two modifications of i.

--
Ian Collins.

On 10 mai, 10:34, brno <brno.barutc...@gmail.com> wrote:
> James Kanze dixit:

> > On May 9, 2:54 am, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
> >> Ian Collins wrote:
> >>> bintom wrote:
> >>>> Is there any reason why the following C++ code behaves as it does ?

> >>>> int i;

> >>>> i=1; cout << (++i)++; Output: 2

> >>> Because it's nonsensical undefined behaviour.

> >> Why is it non-sensical? Why is it undefined?

> > Because the standard says so. You're modifying the same object
> > twice without an intervening sequence point.

> Can you tell what is an intervening sequence point ?

A sequence point that is guaranteed to occur between the two
operations.

In your example, the only sequence points are the ends of each
full expression, and the call and return from the
ostream:perator<<( int ) function. There's nothing between
the ++i (which modifies i), and the (x)++ (where 'x' is the
result of ++i, i.e. i), which also modifies i.

Note that if i was a type with a user defined operator++, the
code would be well defined, since the user defined operator++ is
a function, and both the function call and the return are
sequence points. Note too, however, that sequence points do not
always create a complete ordering: in something like 'f(++i) +
g(++i)', there are still no sequence points between the two
incrementations, so the code has undefined behavior.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On 10 mai, 15:47, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:

> A sequence point is a definite *moment* in the execution of the
> program, at which all the side effects of the previous calculations
> have taken place. There are several situations in which a sequence
> point (SP) is known to exist. First, there is a SP at a semicolon.
> There is a SP after evaluation of all arguments of a function and
> just before the call to that function. There is another SP right
> after the function returns. There is another SP after each object
> is initialised in a definition statement. A comma operator also
> introduces a SP, and so does every logical OR and logical AND
> operator. I think that's about it. I don't think there are other
> sequence points defined.

In 'a ? b : c', between the evaluation of a and either b or c.

> The concept of a sequence point is important for allowing the C++
> compiler to create certain optimizations when it generates code
> from a C++ program. Sequence points are a limitation on the
> execution of the program, so too many of those would mean the
> code cannot be optimized. Too few of them might mean the code
> won't behave predictably.

It's also important to realize that the compiler can reorder
code in an expression significantly, and if any of the legal
reorderings violate the rules, you have undefined behavior. The
classical example is something like:
f( ++ i ) + g( ++ i ) ;
Undefined behavior, since the compiler can legally reorder this
to be as:
tmp1 = ++ i
tmp2 = ++ i
f( tmp1 )
g( tmp2 )
(without any sequence points other than the function calls).

In practice, I (and I suspect that I'm not alone) find it almost
impossible to be 100% sure whether there is a sequence point or
not in some of the more subtle cases. So the general rule is to
just avoid modifying the same variable more than once in an
expression, or modifying it and using it elsewhere in the
expression. About the only exceptions I'll allow are for top
level (not in any parentheses) &&, || and ?:.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34