473,836 Members | 1,560 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

++ devils

Hello all,

My doubt is going to be so primitive that i ask you all to forgive me
beforehand....

Here's the code snippet:

int main()
{
int x=5;
x=x++ + ++x;
printf("%d",x);
return 0;
}

I know that the printf is going to print some value of x which none can
predict accurately for all times for all compilers....Ho wever,why i ask
this is because such type of questions keep appearing in a lot of
Question Papers....

Help me suggest a way to tackle this..

Thanks in advance!

May 21 '06
77 3730

v4vijayakumar wrote:
Vladimir Oka wrote:
v4vijayakumar opined:

Robert Gamble wrote:
> muttaa wrote:


<snip>
> > x=x++ + ++x;


<snip>
> The behavior is undefined, x can now be any value. I would suggest
> you read our FAQ at <http://c-faq.com/expr/index.html>, start with
> question 3.2.

why programming languages have undefined behavior?


Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.


<snip>

It seems that these are problems(?!) with 'sequence points'. When
operands (x++) could be potential expressions then why don't introduce
more 'sequence points'?! any performance issues?!


Why not indeed! Just break it down into easy understandable and weel
defined steps.

This will enable you to spell out the order of execution, and make sure
the result is repeatable. Any compiler worth its salt should optimise
this sort of calculation regardless of how you write it, so there
should be no performance penalty whatsoever. Also, do you really care
about the peroformance if you get the wrong result?

May 22 '06 #21
"v4vijayaku mar" <v4***********@ yahoo.com> writes:
Vladimir Oka wrote:
v4vijayakumar opined:
> Robert Gamble wrote:
>> muttaa wrote:


<snip>
>> > x=x++ + ++x;


<snip>
>> The behavior is undefined, x can now be any value. I would suggest
>> you read our FAQ at <http://c-faq.com/expr/index.html>, start with
>> question 3.2.
>
> why programming languages have undefined behavior?


Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.


<snip>

It seems that these are problems(?!) with 'sequence points'. When
operands (x++) could be potential expressions then why don't introduce
more 'sequence points'?! any performance issues?!


Introducing more sequence points and defining order of evaluation more
tightly would eliminate some, but not all, instances of undefined
behavior. It would also limit the kinds of optimization that
compilers can perform.

Many of the constructs that invoke undefined behavior are just plain
ugly anyway. Take a look at the example above:

x = x++ + ++x;

Why would you want to write such a thing in the first place? Whatever
it's supposed to do, there's certainly a cleaner way to express it.
On one system I just tried, it sets x to 2 * x + 3. If you want to do
that, just do it:

x = 2 * x + 3;

The rules are designed to allow good optimization (which will vary
from one system to another) while making carefully written code
well-defined.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
May 22 '06 #22
We just tried the following expressions in MSVC one by one:-

with initial value of x = 0;

(1) :- x= ++x + ++x gives 4 ( ie., 2 + 2 )
(2) :- x= ++x + ++x + ++x gives 7 ( ie., 2 + 2 + 3 )
(3) :- x = ++x + ++x + ++x + ++x gives 11 ( ie., 2 + 2 + 3 + 4 )
(4) :- x = ++x + ++x + ++x + ++x + ++x gives 16 ( ie., 2 + 2 + 3 +
4 + 5 )

It appears to work like this:-

In (1) first ++x is evaluated to give 1. The second ++x is then
evaluated to give 2. Now the sum of 2 operands around + is 2 + 2 )

In (2) after ++x we get 1 next ++x gives 2; next ++x gives 3. But the
compiler keeps the result of first 2 operands separately ( ie., ++x +
++x = 4 ) and add 3 to give 7.

In (3) and (4) it works in the same way. The result of first 2 operands
is kept separately and then added to the result of the subseqent
operands.
Murli

Keith Thompson wrote:
"v4vijayaku mar" <v4***********@ yahoo.com> writes:
Vladimir Oka wrote:
v4vijayakumar opined:
> Robert Gamble wrote:
>> muttaa wrote:

<snip>

>> > x=x++ + ++x;

<snip>

>> The behavior is undefined, x can now be any value. I would suggest
>> you read our FAQ at <http://c-faq.com/expr/index.html>, start with
>> question 3.2.
>
> why programming languages have undefined behavior?

Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.


<snip>

It seems that these are problems(?!) with 'sequence points'. When
operands (x++) could be potential expressions then why don't introduce
more 'sequence points'?! any performance issues?!


Introducing more sequence points and defining order of evaluation more
tightly would eliminate some, but not all, instances of undefined
behavior. It would also limit the kinds of optimization that
compilers can perform.

Many of the constructs that invoke undefined behavior are just plain
ugly anyway. Take a look at the example above:

x = x++ + ++x;

Why would you want to write such a thing in the first place? Whatever
it's supposed to do, there's certainly a cleaner way to express it.
On one system I just tried, it sets x to 2 * x + 3. If you want to do
that, just do it:

x = 2 * x + 3;

The rules are designed to allow good optimization (which will vary
from one system to another) while making carefully written code
well-defined.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.


May 22 '06 #23

aone1...@yahoo. com wrote:

Do not top post. Your reply belongs below and/or intersperesed with the
post you're replying to. I've fixed it here.

Also, don't quote signatures, unless you're commenting on them.
Keith Thompson wrote:
"v4vijayaku mar" <v4***********@ yahoo.com> writes:
Vladimir Oka wrote:
> v4vijayakumar opined:
> > Robert Gamble wrote:
> >> muttaa wrote:
>
> <snip>
>
> >> > x=x++ + ++x;
>
> <snip>
>
> >> The behavior is undefined, x can now be any value. I would suggest
> >> you read our FAQ at <http://c-faq.com/expr/index.html>, start with
> >> question 3.2.
> >
> > why programming languages have undefined behavior?
>
> Because it is not feasible to define behaviour of every possible
> language construct that the grammar allows -- especially the silly
> ones.

<snip>

It seems that these are problems(?!) with 'sequence points'. When
operands (x++) could be potential expressions then why don't introduce
more 'sequence points'?! any performance issues?!


Introducing more sequence points and defining order of evaluation more
tightly would eliminate some, but not all, instances of undefined
behavior. It would also limit the kinds of optimization that
compilers can perform.

Many of the constructs that invoke undefined behavior are just plain
ugly anyway. Take a look at the example above:

x = x++ + ++x;

Why would you want to write such a thing in the first place? Whatever
it's supposed to do, there's certainly a cleaner way to express it.
On one system I just tried, it sets x to 2 * x + 3. If you want to do
that, just do it:

x = 2 * x + 3;

The rules are designed to allow good optimization (which will vary
from one system to another) while making carefully written code
well-defined.


We just tried the following expressions in MSVC one by one:-

with initial value of x = 0;

(1) :- x= ++x + ++x gives 4 ( ie., 2 + 2 )
(2) :- x= ++x + ++x + ++x gives 7 ( ie., 2 + 2 + 3 )
(3) :- x = ++x + ++x + ++x + ++x gives 11 ( ie., 2 + 2 + 3 + 4 )
(4) :- x = ++x + ++x + ++x + ++x + ++x gives 16 ( ie., 2 + 2 + 3 +
4 + 5 )

It appears to work like this:-

In (1) first ++x is evaluated to give 1. The second ++x is then
evaluated to give 2. Now the sum of 2 operands around + is 2 + 2 )

In (2) after ++x we get 1 next ++x gives 2; next ++x gives 3. But the
compiler keeps the result of first 2 operands separately ( ie., ++x +
++x = 4 ) and add 3 to give 7.

In (3) and (4) it works in the same way. The result of first 2 operands
is kept separately and then added to the result of the subseqent
operands.


Your efforts are a complete and utter waste of time. Since all of the
expressions above invoke Undefined Behaviour, the fact that you got the
results you quote is totally irrelevant. Next time you try your head
may turn to a turnip, or you may observe some pigs performing some
aerobatic manouvers.

Don't waste your time or Usenet bandwith. Just don't do these things.

May 22 '06 #24

ao******@yahoo. com wrote:
We just tried the following expressions in MSVC one by one:-

with initial value of x = 0;

(1) :- x= ++x + ++x gives 4 ( ie., 2 + 2 )
(2) :- x= ++x + ++x + ++x gives 7 ( ie., 2 + 2 + 3 )
(3) :- x = ++x + ++x + ++x + ++x gives 11 ( ie., 2 + 2 + 3 + 4 )
(4) :- x = ++x + ++x + ++x + ++x + ++x gives 16 ( ie., 2 + 2 + 3 +
4 + 5 )

It appears to work like this:-

In (1) first ++x is evaluated to give 1. The second ++x is then
evaluated to give 2. Now the sum of 2 operands around + is 2 + 2 )

In (2) after ++x we get 1 next ++x gives 2; next ++x gives 3. But the
compiler keeps the result of first 2 operands separately ( ie., ++x +
++x = 4 ) and add 3 to give 7.

In (3) and (4) it works in the same way. The result of first 2 operands
is kept separately and then added to the result of the subseqent
operands.
Murli


<snip>

You mean, predictable undefined behavior! :)

May 22 '06 #25
ao******@yahoo. com wrote:

We just tried the following expressions in MSVC one by one:-

with initial value of x = 0;

(1) :- x= ++x + ++x gives 4 ( ie., 2 + 2 )
(2) :- x= ++x + ++x + ++x gives 7 ( ie., 2 + 2 + 3 )
(3) :- x = ++x + ++x + ++x + ++x gives 11 ( ie., 2 + 2 + 3 + 4 )
(4) :- x = ++x + ++x + ++x + ++x + ++x gives 16 ( ie., 2 + 2 + 3 +
4 + 5 )

It appears to work like this:-

In (1) first ++x is evaluated to give 1. The second ++x is then
evaluated to give 2. Now the sum of 2 operands around + is 2 + 2 )

In (2) after ++x we get 1 next ++x gives 2; next ++x gives 3. But the
compiler keeps the result of first 2 operands separately ( ie., ++x +
++x = 4 ) and add 3 to give 7.

In (3) and (4) it works in the same way.
The result of first 2 operands
is kept separately and then added to the result of the subseqent
operands.


That's all about your compiler,
and not at all about the rules of C.

--
pete
May 22 '06 #26

v4vijayakumar wrote:
ao******@yahoo. com wrote:
We just tried the following expressions in MSVC one by one:-

with initial value of x = 0;

(1) :- x= ++x + ++x gives 4 ( ie., 2 + 2 )
(2) :- x= ++x + ++x + ++x gives 7 ( ie., 2 + 2 + 3 )
(3) :- x = ++x + ++x + ++x + ++x gives 11 ( ie., 2 + 2 + 3 + 4 )
(4) :- x = ++x + ++x + ++x + ++x + ++x gives 16 ( ie., 2 + 2 + 3 +
4 + 5 )

It appears to work like this:-

In (1) first ++x is evaluated to give 1. The second ++x is then
evaluated to give 2. Now the sum of 2 operands around + is 2 + 2 )

In (2) after ++x we get 1 next ++x gives 2; next ++x gives 3. But the
compiler keeps the result of first 2 operands separately ( ie., ++x +
++x = 4 ) and add 3 to give 7.

In (3) and (4) it works in the same way. The result of first 2 operands
is kept separately and then added to the result of the subseqent
operands.
Murli


<snip>

You mean, predictable undefined behavior! :)


It's predictable until you compile the code on a different platform.
Or on the same platform with a different compiler. Or the same
platform and compiler with different optimization settings. Or the
same platform, compiler, and optimization settings, but with a
different order of operations.

The behavior is undefined. Individual compilers will do *something*
with the expression, and that *something* will probably be consistent
for a given context, but writing code to anticipate or exploit that
behavior is usually a mistake.

For giggles, I went through all the possible permutations of x++ + x++,
x++ + ++ x, etc., using both VS for Windows and MPW for MacOS, and on
each platform at least one of the permutations gave a "wrong" result,
and the permutations that gave "wrong" results were different between
the two platforms.

May 22 '06 #27
On 22 May 2006 06:43:20 -0700, ao******@yahoo. com wrote:
We just tried the following expressions in MSVC one by one:-


Who cares? Now, tell me the results for the three compilers I use the
most.

--
Al Balmer
Sun City, AZ
May 22 '06 #28
Vladimir Oka wrote:

v4vijayakumar opined:

[...]
> x=x++ + ++x;
[...] why programming languages have undefined behavior?


Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.


Not to mention that forcing a certain behavior for such silly constructs
would impose an unnecessary burden on the compiler writer by preventing
the compiler from generating code which takes advantage of certain
hardware. (For example, a CPU which includes a "load an increment"
operator.) Or by eliminating the ability to optimize code by forcing
the statement to be evaluated in a specific order.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer .h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

May 22 '06 #29
In article <bs************ ********@bt.com >,
Vladimir Oka <no****@btopenw orld.com> wrote:
why programming languages have undefined behavior?
Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.


It's quite feasible, it's just not a choice that C made. For example,
it could be defined that all pointers are checked and an error occurs
if you dereference a bogus one. But this would be against the spirit
of C in two ways: it would impose an overhead on correct code, and it
would prevent C being used for straightforward manipulation of
arbitrary memory locations, for example in device drivers.

The C standard is not designed with the expectation that all programs
are conforming; it guarantees the behaviour of conforming programs and
allows other standards to extend it while still letting C be used as
"a better assembler".

-- Richard
May 22 '06 #30

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.