469,578 Members | 1,756 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,578 developers. It's quick & easy.

j= ++i + ++i ;

The output of "j" in the below code is 8. Can anybody explain me the
concept?

#include<stdio.h>
#include<conio.h>

int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
printf("%d %d", i, j);
getch();
}

Dec 13 '06 #1
26 1435
Rajat <ra********@gmail.comwrote:
The output of "j" in the below code is 8. Can anybody explain me the
concept?
Yes: Reading the FAQ first helps.

http://c-faq.com/expr/evalorder1.html

Read 3.1, 3.2, and 3.3.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Dec 13 '06 #2
Rajat wrote:
>
The output of "j" in the below code is 8. Can anybody explain me
the concept?

#include<stdio.h>
#include<conio.h>

int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
printf("%d %d", i, j);
getch();
}
Without the source of getch() we cannot tell. In addition there is
no such header as <conio.hin standard c. Also, your main fails
to return a value. Further yet, the assignment to j invokes
undefined behavior. An outstanding achievement, so many errors in
so short a program.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

Dec 13 '06 #3
Rajat wrote:
The output of "j" in the below code is 8. Can anybody explain me the
concept?
Yes.

After:
int i = 2;
int j = 0;
the line:
j= ++i + ++i ;
doesn't mean anything. (See the FAQ for details.) So the implementation
can do whatever comes naturally to it. Here, what comes naturally
looks like incrementing `i` twice, which is what you wrote, which
got 4, and then adding `4` to `4` to get `8`. But another implementation
could increment `i` /once/ and add `3` to `3` to get `6`.

[You ask /why/ it could choose to implement `i` once? Well, `++i`
means "deliver i+1 and store that value in i at a convenient moment
before the next sequence point [1]". Since it's Undefined Behaviour to
update the same variable twice before the next sequence point, and
the compiler is allowed to assume you, the All-Knowing Programmer,
won't have an Undefined Behaviour in your code, it only needs to
remember "I must increment `i`". The second `++i` remembers the same
thing. So `i` gets incremented only once, at a convenient moment,
say after the additions happen.]

Another implementation might recognise this statement as producing
Undefined Behaviour and generate a diagnostic message and code
equivalent to `j = 17` (or `42` or `0` or `-1` or `MAX_INT` or ...)

Another implementation runs on a machine with a Increment Both
instruction:

ib Ra, Rb ;;; Ra += 1, Rb += 1

However since no-one would use ib with the same register (since
you can use `inc Rx, #2`), the operation code for `ib Rx, Rx`
means `Rx := 0`. Since the C compiler can assume that the
undefined behaviour of updating the same variable twice can't
legally happen, it compiles your code as:

add Rj, Ri, Ri
add Rj, Rj, #2
ib Ri, Ri

`j` gets the value you might have been expecting, but `i` is
unexpectedly 0 ...

[1] Here the sequence point is at the end of the statement; you can
think of it as being marked by the semicolon.

--
Chris "Perikles triumphant" Dollin
"- born in the lab under strict supervision -", - Magenta, /Genetesis/

Dec 13 '06 #4

Rajat wrote:
The output of "j" in the below code is 8. Can anybody explain me the
concept?

#include<stdio.h>
#include<conio.h>

int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
The above line invokes undefined behavior, so the compiler is under no
obligation to generate a meaningful result.

Contrary to popular belief, the side effect of the preincrement
operator (adding 1 to i) does not have to be applied immediately after
the expression has been evaluated. Nor is there any guarantee that the
expressions are evaluated in the order that they're written. For
example, given the statement

i = j++ * --k;

it's possible that --k is evaluated before j++, and that the side
effects of both expressions (adding 1 to j and subtracting 1 from k)
are not applied until after both expressions have been evaluated.

The tradeoff for this kind of flexibility is that the result of an
expression like

i = i++
j = i++ + i++
a[i++] = i++

is explicitly undefined; in other words, there is no correct result for
such an expression.
printf("%d %d", i, j);
getch();
}
Dec 13 '06 #5
"Rajat" <ra********@gmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
The output of "j" in the below code is 8. Can anybody explain me the
concept?

#include<stdio.h>
#include<conio.h>

int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
printf("%d %d", i, j);
getch();
}
I see you are working in VS...

The distinction between ++i and i++ is that the former is evaluated before the
expression it is found in, and i++ is evaluated after.
So if
int i=2;
int j=0;
then after j = i++; j will be 2, and i will be 3. However, after j = ++i; j will
be 3 and i will be 3.
Therefore, i will be increased by 1 twice before the expression j = ++i + ++i
will be evaluated. The order of execution (for VS!) is this:
inc i
inc i
add j, i, i
Other compilers might act differently.

--
"It is easy in the world to live after the world's oppinion; it easy in solitude
to live after our own; but the great man is he who in the midst of the crowd
keeps with perfect sweetness the independence of solitude."
Ralph Waldo Emerson, Self-reliance 1841
http://pinpoint.wordpress.com/

Dec 14 '06 #6
Also, your main fails to return a value.

I see this statement a lot. Does the quote below from the standard mean
it's fine to just reach the } that terminate the main function? Or am I
misreading something?

5.1.2.2.3 Program termination
If the return type of the main function is a type compatible with int,
.... reaching the } that terminates the main function returns a value of 0.
Dec 14 '06 #7
Jim Cook <co****@strobedata.comwrites:
I see this statement a lot. Does the quote below from the standard
mean it's fine to just reach the } that terminate the main function?
Yes, but it's new in C99 and thus not widely supported.
--
"For those who want to translate C to Pascal, it may be that a lobotomy
serves your needs better." --M. Ambuhl

"Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt
Dec 14 '06 #8
Jim Cook <co****@strobedata.comwrites:
>Also, your main fails to return a value.
Please don't snip attribution lines. The above was written by CBFalconer.
I see this statement a lot. Does the quote below from the standard
mean it's fine to just reach the } that terminate the main function?
Or am I misreading something?

5.1.2.2.3 Program termination
If the return type of the main function is a type compatible with int,
... reaching the } that terminates the main function returns a value
of 0.
Yes, that's correct -- for C99. C90 does not have that rule; in C90,
reaching the end of main() causes an unspecified result to be returned
to the calling environment.

I recommend *always* explicitly returning a value from main() (either
by a return statement or by a call to exit()), for two reasons.
First, most compilers don't yet support C99, and I don't know how many
implement this rule. (But a conforming C90 compiler *could* implement
the rule anyway; the unspecified result would just happen to be 0.)
Second, it's extremely easy to just write a return statement and avoid
the issue altogether.

(There's also a question of whether the rule applies to recursive
calls to main(), but the answer to that is simple: don't call main()
recursively.)

--
Keith Thompson (The_Other_Keith) 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.
Dec 14 '06 #9

"Rajat" <ra********@gmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
The output of "j" in the below code is 8. Can anybody explain me the
concept?
Yes confusion :D

LOL

Bye,
Skybuck.
#include<stdio.h>
#include<conio.h>

int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
printf("%d %d", i, j);
getch();
}

Dec 14 '06 #10
Jim Cook wrote:
>
>Also, your main fails to return a value.

I see this statement a lot. Does the quote below from the standard
mean it's fine to just reach the } that terminate the main function?
Or am I misreading something?

5.1.2.2.3 Program termination
If the return type of the main function is a type compatible with
int, ... reaching the } that terminates the main function returns
a value of 0.
That is from C99. Most systems adhere to C90, where it is an
error. There is no reason not to write code that is legitimate
under all standards.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Dec 14 '06 #11
Thanks a lot for your help

Dec 14 '06 #12


The output of "j" in the below code is 8. Can anybody explain me the
concept?Yes: Reading the FAQ first helps.

http://c-faq.com/expr/evalorder1.html

Read 3.1, 3.2, and 3.3.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Thank you

Dec 14 '06 #13


On Dec 13, 7:30 pm, CBFalconer <cbfalco...@yahoo.comwrote:
Rajat wrote:
The output of "j" in the below code is 8. Can anybody explain me
the concept?
#include<stdio.h>
#include<conio.h>
int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
printf("%d %d", i, j);
getch();
}Without the source of getch() we cannot tell. In addition there is
no such header as <conio.hin standard c. Also, your main fails
to return a value. Further yet, the assignment to j invokes
undefined behavior.
Yes, mistakes makes a man perfect. Atleast I know whats wrong in the
statement.
"j=++i + ++i"
But I cannot agree with you. getch(); uses the header conio.h itself.

Please point me out if I am wrong.

Dec 14 '06 #14
On Wed, 13 Dec 2006 23:17:03 +0100, "Sourcerer"
<en****@MAKNIgmail.comwrote in comp.lang.c:
"Rajat" <ra********@gmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
The output of "j" in the below code is 8. Can anybody explain me the
concept?

#include<stdio.h>
#include<conio.h>

int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
printf("%d %d", i, j);
getch();
}

I see you are working in VS...
What makes you say that?

And please don't post nonsense like this. There is an enormous amount
of incorrect information and poor terminology in your reply.

The distinction between ++i and i++ is that the former is evaluated before the
expression it is found in, and i++ is evaluated after.
Complete and utter rubbish. ++i evaluates to the value of i after it
is incremented. i++ evaluates to the value of i before it is
incremented. If a prefix or postfix increment expression is part of a
larger expression, I guarantee you that it is evaluated during
evaluation of the larger expression, and most certainly not afterward.

In the snipped:

int i = 2;
int j = 3;
int k;
k = i++ + j++;

....I absolutely guarantee that both of the subexpressions on the right
hand side will be evaluated before the value 5 is assigned to k, not
afterwards.
So if
int i=2;
int j=0;
then after j = i++; j will be 2, and i will be 3. However, after j = ++i; j will
be 3 and i will be 3.
There is no "then" or "before" or "after" in the OP's expression,
these concepts do not exist without intervening sequence points. Only
sequence points impose ordering and "before" and "after".
Therefore, i will be increased by 1 twice before the expression j = ++i + ++i
will be evaluated. The order of execution (for VS!) is this:
No what happens is that the behavior is undefined specifically by the
C standard. It attempts to modify the value of an object more than
once without an intervening sequence point.
inc i
inc i
add j, i, i
Other compilers might act differently.
The value is of no interest and no importance, since the code is no
longer C.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Dec 14 '06 #15
Rajat wrote:
CBFalconer <cbfalco...@yahoo.comwrote:
>Rajat wrote:
>>The output of "j" in the below code is 8. Can anybody explain me
the concept?
>>#include<stdio.h>
#include<conio.h>
>>int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
printf("%d %d", i, j);
getch();
}

Without the source of getch() we cannot tell. In addition there is
no such header as <conio.hin standard c. Also, your main fails
to return a value. Further yet, the assignment to j invokes
undefined behavior.

Yes, mistakes makes a man perfect. Atleast I know whats wrong in the
statement.
"j=++i + ++i"
But I cannot agree with you. getch(); uses the header conio.h itself.

Please point me out if I am wrong.
As I said, there is no such header as <conio.hin standard C. It
is probably some sort of extension supplied by your non-standard
system. In c.l.c we deal only with the ISO standard C language, so
to use other routines you have to present their complete source,
written in standard C.

For all I know that getch call might wipe out your entire hard
disk, or launch nuclear missiles at N. Korea, or insult Allah, or
exterminate holy cows. We are not here to make guesses, even if
fairly well educated guesses.

Read the following links:

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/(C99)
<http://www.dinkumware.com/refxc.html (C-library}
<http://gcc.gnu.org/onlinedocs/ (GNU docs)
<http://clc-wiki.net (C-info)

Dec 14 '06 #16
In article <45***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
....
>Read the following links:

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/(C99)
<http://www.dinkumware.com/refxc.html (C-library}
<http://gcc.gnu.org/onlinedocs/ (GNU docs)
<http://clc-wiki.net (C-info)
Yes, and also:

Useful clc-related links:

http://en.wikipedia.org/wiki/Aspergers
http://en.wikipedia.org/wiki/Clique
http://en.wikipedia.org/wiki/C_programming_language

Dec 14 '06 #17
"Jack Klein" <ja*******@spamcop.netwrote in message
news:lb********************************@4ax.com...
On Wed, 13 Dec 2006 23:17:03 +0100, "Sourcerer"
<en****@MAKNIgmail.comwrote in comp.lang.c:
>"Rajat" <ra********@gmail.comwrote in message
news:11**********************@n67g2000cwd.googleg roups.com...
The output of "j" in the below code is 8. Can anybody explain me the
concept?

#include<stdio.h>
#include<conio.h>

int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
printf("%d %d", i, j);
getch();
}

I see you are working in VS...

What makes you say that?
conio.h is not included in standard C. It is included in VS' C++, and getch() is
declared there. This is what makes me say it.

<snip>
>The distinction between ++i and i++ is that the former is evaluated before
the
expression it is found in, and i++ is evaluated after.

Complete and utter rubbish. ++i evaluates to the value of i after it
is incremented. i++ evaluates to the value of i before it is
incremented. If a prefix or postfix increment expression is part of a
larger expression, I guarantee you that it is evaluated during
evaluation of the larger expression, and most certainly not afterward.
Effectively, however, when you have a prefix increment expression(s), the result
of the expression:
j = ++i + ++k + ++l;
Would be the same as:
++i;
++k;
++l;
j = i + k + l;
With postfix, the result of the expression:
j = i++ + k++ + l++;
Would be the same as:
j = i + k + l;
i++;
k++;
l++;
The only thing different would be the order of execution.
In the snipped:

int i = 2;
int j = 3;
int k;
k = i++ + j++;

...I absolutely guarantee that both of the subexpressions on the right
hand side will be evaluated before the value 5 is assigned to k, not
afterwards.
Very well then. I, however, guarantee you that I can make a compiler which would
generate code in such a way that the subexpressions would be evaluated after the
value 5 is assigned to k.
>So if
int i=2;
int j=0;
then after j = i++; j will be 2, and i will be 3. However, after j = ++i; j
will
be 3 and i will be 3.

There is no "then" or "before" or "after" in the OP's expression,
these concepts do not exist without intervening sequence points. Only
sequence points impose ordering and "before" and "after".
Let me rephrase:
So if
int i=2;
int j=0;
then after the execution of instructions generated from the expression j=i++; j
will be 2, and i will be 3. However, after the execution of instructions
generated from the expression j=++i; j will be 3 and i will be 3 (of course, I'm
keeping the symbolic names of the variables purely for the sake of clarity).
>Therefore, i will be increased by 1 twice before the expression j = ++i + ++i
will be evaluated. The order of execution (for VS!) is this:

No what happens is that the behavior is undefined specifically by the
C standard. It attempts to modify the value of an object more than
once without an intervening sequence point.
I've mentioned twice that I'm talking about a compiler built into the VS. I
happen to know that it works this way. You can refer to the standard C, but tell
me how many compilers actually respect the standard to the last letter? VS works
this way and that is what I said.

<snip>

--
"It is easy in the world to live after the world's oppinion; it easy in solitude
to live after our own; but the great man is he who in the midst of the crowd
keeps with perfect sweetness the independence of solitude."
Ralph Waldo Emerson, Self-reliance 1841
http://pinpoint.wordpress.com/

Dec 14 '06 #18
Sourcerer said:
"Jack Klein" <ja*******@spamcop.netwrote in message
news:lb********************************@4ax.com...
>On Wed, 13 Dec 2006 23:17:03 +0100, "Sourcerer"
<en****@MAKNIgmail.comwrote in comp.lang.c:
>>"Rajat" <ra********@gmail.comwrote in message
<snip>
> getch();
}

I see you are working in VS...

What makes you say that?

conio.h is not included in standard C.
Correct.
It is included in VS' C++,
And Microsoft's C implementation, and Borland's C implementation, and
DJGPP's C implementation, and heaven knows what else - but there has been
no successful effort (and AFAIK no effort whatsoever) to standardise its
semantics.
and
getch() is declared there.
Or in cursesw.h, of course. Or in any programmer-defined header or source
file that any programmer sees fit to write. And, again, there is no one
correct definition of getch's behaviour. It will do what it's programmed to
do, and since anyone can write their own, a getch function call in a
comp.lang.c article can only reasonably be considered ungrokkable, just as
are calls to functions such as hcteg, rcsrlc, hpargtini, and so on.
This is what makes me say ["I see you are working in VS"].
....or Borland C, or gcc, or DJGPP, or... or... or...

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 14 '06 #19
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:cf******************************@bt.com...
Sourcerer said:
>"Jack Klein" <ja*******@spamcop.netwrote in message
news:lb********************************@4ax.com.. .
>>On Wed, 13 Dec 2006 23:17:03 +0100, "Sourcerer"
<en****@MAKNIgmail.comwrote in comp.lang.c:

"Rajat" <ra********@gmail.comwrote in message

<snip>
>> getch();
}

I see you are working in VS...

What makes you say that?

conio.h is not included in standard C.

Correct.
>It is included in VS' C++,

And Microsoft's C implementation, and Borland's C implementation, and
DJGPP's C implementation, and heaven knows what else - but there has been
no successful effort (and AFAIK no effort whatsoever) to standardise its
semantics.
Thanks for the info. Now I will know. Luckily, I seem to have been correct this
time, since the thread starter did not deny it.

<snip>

Dec 14 '06 #20
Sourcerer said:

<snip>
Luckily, I seem to have been correct
this time, since the thread starter did not deny it.
You might think so, but in fact OPs often read just one or two replies and
then vanish forever. In this case, he did offer a "thank you", but then
some OPs say "thank you" out of simple courtesy, even when the advice
received was completely out to lunch.

We will probably never know either way whether the OP uses Visual Studio. In
any case, if the OP's implementation is relevant then his question is
off-topic.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 14 '06 #21
"Sourcerer" <en****@MAKNIgmail.comwrites:
"Jack Klein" <ja*******@spamcop.netwrote in message
news:lb********************************@4ax.com...
>On Wed, 13 Dec 2006 23:17:03 +0100, "Sourcerer"
<en****@MAKNIgmail.comwrote in comp.lang.c:
[...]
>>Therefore, i will be increased by 1 twice before the expression
j = ++i + ++i will be evaluated. The order of execution (for VS!)
is this:

No what happens is that the behavior is undefined specifically by the
C standard. It attempts to modify the value of an object more than
once without an intervening sequence point.

I've mentioned twice that I'm talking about a compiler built into the
VS. I happen to know that it works this way. You can refer to the
standard C, but tell me how many compilers actually respect the
standard to the last letter? VS works this way and that is what I said.
VS is what, Visual Studio? Please don't assume that all your readers
happen to know what VS means.

The behavior of "j = ++i + ++i" is undefined. That means that
*anything* a particular implementation does with it is conforming.

The only sensible approach to this is to avoid writing code like that
in the first place. Whatever you happen to mean by "j = ++i + ++i",
there's certainly a clearer way to express your intent *without*
forcing anyone reading your code to guess what you're doing. For
example, you could write:

j = 2 * i + 1;
i += 2;

(adjust the "+ 1" as needed).

If you're tracking down a problem in existing code, it can be helpful
to know how a given implementation handles this kind of thing. If
you're writing new code, you *should not care*. There is no point in
writing code like this that depends on the behavior of one particular
implementation, and that will inevitably break when compiled with
another compiler, or with a newer or older release of the same
compiler. (Does VS *document* this behavior? If not, there's no
reason to assume it won't change.)

The standard is a contract between implementers and users. And yes, C
compilers do conform closely to the standard, at least for things like
this. (There are issues involving the differences between the C90 and
C99 standards, OS-specific behavior of some of the runtime library,
and various extensions; none of these are relevant to expression
evaluation.) If the VS compiler, or any C compiler, fails to conform
in this area, it's a bug, and you should report it.

--
Keith Thompson (The_Other_Keith) 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.
Dec 14 '06 #22
"Sourcerer" writes:
"Rajat" <ra********@gmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
>The output of "j" in the below code is 8. Can anybody explain me the
concept?

#include<stdio.h>
#include<conio.h>

int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
printf("%d %d", i, j);
getch();
}

I see you are working in VS...
I think you are guessing. I would bet a large amount of money that will
compile with some Borland products.
Dec 14 '06 #23
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
....
>The standard is a contract between implementers and users. And yes, C
compilers do conform closely to the standard, at least for things like
this. (There are issues involving the differences between the C90 and
C99 standards, OS-specific behavior of some of the runtime library,
and various extensions; none of these are relevant to expression
evaluation.) If the VS compiler, or any C compiler, fails to conform
in this area, it's a bug, and you should report it.
You know, you really are a dork. You just got done saying (a few
paragraphs back, in the section that I snipped), quite correctly, that
*any* behavior is conforming - that anything a compiler/implementation
does with this is within the standard. So, how could "the VS compiler,
or any C compiler, fail[s] to conform in this area"? How could there
possibly be anything to report?

Dec 14 '06 #24
Rajat wrote:
The output of "j" in the below code is 8. Can anybody explain me the
concept?

#include<stdio.h>
#include<conio.h>

int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
printf("%d %d", i, j);
getch();
}
Easiest way to understand this is:
1) Convert all ++var (or --var) to var by prepending ++var to the line
2) Convert all var++ to var appending var++ to that line.
(Though this never failed on a variety of compilers and machine
combinations I have tested so far, yet no guarantee)

for ex:
you may rewrite
/******* Before ********/
j = ++i + ++i + i++ + ++i;
/***********************/

to
/****** After **********/
++i;
++i;
++i;
j = i + i + i + i;
i++;
/**********************/

May be this will remove all the confusions and make the code easier to
understand. -MJ

Dec 15 '06 #25
MJ_India said:
Rajat wrote:
>The output of "j" in the below code is 8. Can anybody explain me the
concept?

#include<stdio.h>
#include<conio.h>

int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
printf("%d %d", i, j);
getch();
}

Easiest way to understand this is:
1) Convert all ++var (or --var) to var by prepending ++var to the line
2) Convert all var++ to var appending var++ to that line.
Wrong. The easiest way to understand it is to realise that it's broken code,
which should not be used. Your suggested evaluation order is only one
possibility, and no compiler is bound by it.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 15 '06 #26
MJ_India wrote:
Rajat wrote:
>The output of "j" in the below code is 8. Can anybody explain me the
concept?

#include<stdio.h>
#include<conio.h>

int main(void)
{
int i=2;
int j=0;
j= ++i + ++i ;
printf("%d %d", i, j);
getch();
}

Easiest way to understand this is:
1) Convert all ++var (or --var) to var by prepending ++var to the line
2) Convert all var++ to var appending var++ to that line.
(Though this never failed on a variety of compilers and machine
combinations I have tested so far, yet no guarantee)
No. No. NO. NONONONO.

/If/ the code means something, /then/ [in some circumstances] your
rewritten code will mean the same thing. (It will, for example,
get /the wrong answer/ if the unrewritten code has increments
after embedded sequence points -- eg the right operands of &&
or ||).

But if the code is meaningless, then all your rewrite does is
choose an arbitrary possible meaning.

`++i + ++i` is defined by the Standard to be undefined. It doesn't
matter how you rewrite it. /That/ is the important thing to
understand:
for ex:
you may rewrite
/******* Before ********/
j = ++i + ++i + i++ + ++i;
/***********************/

to
/****** After **********/
++i;
++i;
++i;
j = i + i + i + i;
i++;
/**********************/
You may also rewrite it to

j = 1829;

and be /just as correct/. Note /also/ that given:

int example( int *a, int i, int j )
{ return a[i]++ + a[j]++; }

int ugh[] = {0, 1};

then the expression `example( ugh, 0, 1 )` is well-defined,
but the expression `example( ugh, 1, 1 )` is not.

--
Chris "Perikles triumphant" Dollin
"The path to the web becomes deeper and wider" - October Project

Dec 15 '06 #27

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by William C. White | last post: by
2 posts views Thread by Albert Ahtenberg | last post: by
3 posts views Thread by James | last post: by
reply views Thread by Ollivier Robert | last post: by
1 post views Thread by Richard Galli | last post: by
4 posts views Thread by Albert Ahtenberg | last post: by
1 post views Thread by inderjit S Gabrie | last post: by
2 posts views Thread by Jack | last post: by
3 posts views Thread by Sandwick | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.