Board index » cppbuilder » Re: operator ++ doubts

Re: operator ++ doubts


2005-03-10 12:28:02 PM
cppbuilder105
"Duane Hebert" < XXXX@XXXXX.COM >wrote in message
Quote

>>>executed (line: int result = (i++) + (i++);)?

The problem is that the order of evaluation is undefined.
Stroustrup has a link at his FAQ that may interest you:
www.research.att.com/~bs/bs_faq2.html#evaluation-order
No, you are confusing different issues. It's undefined behavior in the
original code due to absence of sequence point. Stroustrup is talking about
the order of evaluation of the arguments in a function call. If "i" were a
class that had overloaded operator+ then evaluation order would be a
relevant issue.
J
 
 

Re:Re: operator ++ doubts

J Alexander wrote:
Quote
No, you are confusing different issues. It's undefined behavior in the
original code due to absence of sequence point. Stroustrup is talking about
the order of evaluation of the arguments in a function call. If "i" were a
class that had overloaded operator+ then evaluation order would be a
relevant issue.
Did you read that complete section of the Stroustrup article? The bold
title is "What's the value of i++ + i++?" The exactly the code the
original poster gave. The stuff about arguments in a function call he
says is a related example.
--
Gillmer J. Derge [TeamB]
 

Re:Re: operator ++ doubts

"Gillmer J. Derge [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
J Alexander wrote:
>No, you are confusing different issues. It's undefined behavior in the
>original code due to absence of sequence point. Stroustrup is talking
>about the order of evaluation of the arguments in a function call. If "i"
>were a class that had overloaded operator+ then evaluation order would be
>a relevant issue.

Did you read that complete section of the Stroustrup article? The bold
title is "What's the value of i++ + i++?" The exactly the code the
original poster gave. The stuff about arguments in a function call he
says is a related example.
I believe J Alexander addressed the first line of Duane Herbert's answer,
which was "The problem is that the order of evaluation is undefined".
Cheers,
Serge
 

{smallsort}

Re:Re: operator ++ doubts

Alan Bellingham wrote:
Quote
Wiljo < XXXX@XXXXX.COM >wrote:


>int i = 0;
>int result = (++i) + (++i);
>
>Here i becomes 2 and result would be 4 (2 + 2).


_MIGHT_ be 4. But the expression is allowed to generate 4128423 if it
feels like it, since you've invoked undefined behaviour.

Allright, I will agree that one is invoking Undefined Behaviour with this
expression. And the result can evaluate to a number of values, depending on the
compiler and whether or not optimizations are enabled. So result can evaluate to
either 2, 3 or 4, but certainly *not* 4128423 or some other strange random
value. The value of "i" will evaluate to either 1 or 2, because it is indeed not
clear if the value of "i" is stored already after the first increment and before
the second.
Quote
Highly unlikely, but the language at this point takes the point of view
that it will not define the effect of modifying the same variable twice
and also trying to read it 'between two sequence points'. In effect,
it's refusing to say that the modified value has been written out until
it gets to the terminating semi-colon, and that therefore the expression
could increment 0 twice.

Other languages make other decisions, but C (and thus C++) tries to put
as few limitations on the underlying code as possible.

Alan Bellingham
I will admit that I was not entirely correct with this. So I would say to this:
"avoid constructions with multiple object modifications in one expression at all
times".
Wiljo.
 

Re:Re: operator ++ doubts

Remy Lebeau (TeamB) wrote:
Quote
>int i = 0;
>int result = (++i) + (++i);
>
>Here i becomes 2 and result would be 4 (2 + 2).


More likely, it will become 3 ((1 + 2) or (2 + 1)).

Well, now even I am confused. If "i" were a class (see new thread of this post)
it will be 3 (1 + 2), but with "i" being just an int the result of the
evaluation must be consideren Undefined. It depends on the compiler and whether
or not optimizations are set. Result can evaluate to maybe 1, 2, 3 or even 4.
When one might test this code on a compiler, it would generate one of the
possible answers, but on another compiler of another vendor or optimizations set
or not, the result could be one of the other values. Thus clearly this must be
avoided at all times. The code might be nice and compact, but it's behaviour
*must* be considered Undefined.
Wiljo.
 

Re:Re: operator ++ doubts

Chris Uzdavinis (TeamB) wrote:
Quote
>int i = 0;
>int result = (++i) + (++i);

Two modifications to data at the same address without an intervening
sequence point results in undefined behavior.

I will agree with you on that. It is better to avoid these kind of constructions
alltogether.
Wiljo.
 

Re:Re: operator ++ doubts

Gillmer J. Derge [TeamB] wrote:
Quote
Wiljo wrote:

>There is *no* Undefined Behaviour here, although it looks like it.
>This is just the interpretation of the viewer. I can see what happens,
>but not everyone is clear about this. Better avoid these constructions
>as much as possible.


Alan is right on this. See question 3.2 here for details:

www.faqs.org/faqs/C-faq/faq

Glad to be corrected on this topic. I must agree with the given answer for
question 3.2. The variable "i" will be incremented some time before the
expression is considered "finished". But this can be implemented differently by
venders of different compilers. One might increment the value immediately after
it is read the first time, and thus have another value the next time it is read.
Or one might increment the value twice after the value has been used twice.
Either way would be correct from the compilers point of view, but it's result
would be different.
Unless "i" is defined as a class, see my post in the new thread of this topic,
then it's behaviour will be more precise. When "i" is a class the ++ operator is
a function that either returns the prior or new value, after the increment. This
++ function will be called twice, and both return a different values. "i" Will
have been incremented by the time the second call is made. Although the result
will not be Undefined it must be considered Undefined, because one can't see
this from just looking at the line of code.
Wiljo.
 

Re:Re: operator ++ doubts

Alan Bellingham wrote:
Quote
Oh, now that's unfair, claiming Bjarne Stroustrup as an authority.
What's he know about C++ ...

Alan Bellingham
As far as I know the problem at hand is just a C problem. There is no C++
involved with this at all. So turning to Bjarne Stroustrup as an authority is in
my book not unfair.
See my other posts for my comment on this matter. A multiple successive change
to an object during the same expression, can behave differently between classes
and simple objects. It is all about the order in which things are executed
internally by the compiler. With a class this order is likely to be more precise
and defined. This doesn't mean that the same line of code with classes is less
undefined. One still doesn't know what the right order of execution will be,
because it is not evident from the expression that classes are being used.
Although the answer of the evaluation might be more along the lines of what is
to be expected, the expression stays suspect nevertheless.
Wiljo.
 

Re:Re: operator ++ doubts

Wiljo < XXXX@XXXXX.COM >wrote:
Quote
Allright, I will agree that one is invoking Undefined Behaviour with this
expression. And the result can evaluate to a number of values, depending on the
compiler and whether or not optimizations are enabled. So result can evaluate to
either 2, 3 or 4, but certainly *not* 4128423 or some other strange random
value. The value of "i" will evaluate to either 1 or 2, because it is indeed not
clear if the value of "i" is stored already after the first increment and before
the second.
I would be extremely surprised indeed if the value did come out as 'some
random value', because the underlying code ought to be sane within the
laws of computing. But, if the compiler itself had spotted that you were
doing this, and had deliberately inserted code to produce the random
value, it wouldn't be wrong.
Gratuitously strange, but not wrong.
When in the area of undefined behaviour, anything, but anything, is then
allowed to happen by the rules, because the rules say "From here on, we
give up".
Quote
I will admit that I was not entirely correct with this. So I would say to this:
"avoid constructions with multiple object modifications in one expression at all
times".
Which I _do_ agree with (assuming you meant "multiple modifications of
the same object").
Alan Bellingham
--
ACCU Conference 2005 - 20-23 April, Randolph Hotel, Oxford, UK
 

Re:Re: operator ++ doubts

Alan Bellingham wrote:
Quote
Which I _do_ agree with (assuming you meant "multiple modifications of
the same object").

That is what I meant.
Wiljo.
 

Re:Re: operator ++ doubts

"Sergiy Kanilo" < XXXX@XXXXX.COM >writes:
Quote
I believe J Alexander addressed the first line of Duane Herbert's answer,
which was "The problem is that the order of evaluation is undefined".
Order of evaluation is _unspecified_.
The behavior of multiple writes to the same address without an
intervening sequence point is _undefined_.
--
Chris (TeamB);
 

Re:Re: operator ++ doubts

Wiljo < XXXX@XXXXX.COM >writes:
Quote
Remy Lebeau (TeamB) wrote:

>>int i = 0;
>>int result = (++i) + (++i);
>>
>>Here i becomes 2 and result would be 4 (2 + 2).
>More likely, it will become 3 ((1 + 2) or (2 + 1)).
>
Well, now even I am confused. If "i" were a class (see new thread of
this post) it will be 3 (1 + 2), but with "i" being just an int the
result of the evaluation must be consideren Undefined.
Actually, not just the evaluation is undefined, but the behavior of
the entire program.
Quote
It depends on
the compiler and whether or not optimizations are set. Result can
evaluate to maybe 1, 2, 3 or even 4.
Or 17. Or the program can send a hate mail message. Or the computer
can catch fire. Anything can happen. Literally anything.
Quote
Thus clearly this must be avoided at all times.
Exactly.
 

Re:Re: operator ++ doubts

"Chris Uzdavinis (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
"Sergiy Kanilo" < XXXX@XXXXX.COM >writes:

>I believe J Alexander addressed the first line of Duane Herbert's answer,
>which was "The problem is that the order of evaluation is undefined".

Order of evaluation is _unspecified_.
IMHO we can talk about order of evaluation only
if we can guarantee that evaluation takes place
Quote
The behavior of multiple writes to the same address without an
intervening sequence point is _undefined_.
Exactly
Cheers,
Serge
 

Re:Re: operator ++ doubts

"J Alexander" < XXXX@XXXXX.COM >wrote in message news:422fccf1$ XXXX@XXXXX.COM ...
Quote
"Duane Hebert" < XXXX@XXXXX.COM >wrote in message
news:422f3034$ XXXX@XXXXX.COM ...
>
>>>>executed (line: int result = (i++) + (i++);)?
>
>The problem is that the order of evaluation is undefined.
>Stroustrup has a link at his FAQ that may interest you:
>www.research.att.com/~bs/bs_faq2.html#evaluation-order

No, you are confusing different issues. It's undefined behavior in the
original code due to absence of sequence point. Stroustrup is talking about
the order of evaluation of the arguments in a function call. If "i" were a
class that had overloaded operator+ then evaluation order would be a
relevant issue.
Which i++ is evaluated first? Why is the absence of a sequence
point undefined? It amounts to the same thing.
 

Re:Re: operator ++ doubts

"Wiljo" < XXXX@XXXXX.COM >wrote in message news:423026e7$ XXXX@XXXXX.COM ...
Quote
Alan Bellingham wrote:

>Oh, now that's unfair, claiming Bjarne Stroustrup as an authority.
>What's he know about C++ ...
>
>Alan Bellingham

As far as I know the problem at hand is just a C problem. There is no C++
involved with this at all. So turning to Bjarne Stroustrup as an authority is in
my book not unfair.
You're saying it's not unfair but your tone implies that you
meant not fair <g>
At any rate, we aren't using C. We're using C++. It's incorrect
in C++ and defined as so by an authority of C++. It has nothing
to do with what's correct or incorrect in C IMO.