Any difference???

[anuradhathakur.it]

Is there any difference between i++ & i=i+1...

I mean, I read somewhere that i++ is faster then i=i+1..
But as both of them is performing same operations....how can one be
faster than another...

 

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

Is there any difference between i++ & i=i+1...

I mean, I read somewhere that i++ is faster then i=i+1..
But as both of them is performing same operations....how can one be
faster than another...

In effect there's no difference, and on a good compiler there should
be none in efficiency either. However I think you confused it with the
question of ++i vs i++, where there's a difference. In the case of i++
the value returned is i before the increment whereas ++i will return
the value of i *after* the increment. This means that i++ must make a
copy of the old value before incrementing and then return the copy.
Most compilers can probably optimize away the difference if the result
is not assigned, at least for built-in types.

When using iterators on the other hand there can be a more noticable
difference since an iterator is larger so more have to be copied, for
that reason ++i is generally preferred when just incrementing.

 

[Zeppe]

In effect there's no difference, and on a good compiler there should
be none in efficiency either.

Well, there is, indeed. when i = 1, i++ will return 1 and i=i+1 will
return 2. So, actually the second form can be implemented more efficiently.

Regards,

Zeppe

 

[Asm23]

Is there any difference between i++ & i=i+1...

I mean, I read somewhere that i++ is faster then i=i+1..
But as both of them is performing same operations....how can one be
faster than another...

on the assamble side:

the compiler could translate the "i++" to asm: "INC reg"
then the i=i+1 could be "ADD reg,1"

maybe the "INC" instruction runs faster than the "ADD" .
But those difference depends on the optimization method of the
compiler.

 

[Victor Bazarov]

on the assamble side:

the compiler could translate the "i++" to asm: "INC reg"
then the i=i+1 could be "ADD reg,1"

Could. Or they both could result in the same INC instruction. The
compilers of today are relatively clever to recognise 'i=i+1' as
a specific pattern.

maybe the "INC" instruction runs faster than the "ADD" .
But those difference depends on the optimization method of the
compiler.

The question is, would such a difference be noticeable in the big
picture? And, of course, there is the second question, whether the
operator+(int) and operator++(int) are overloaded for the type of
the 'i' object and how well.

V

 

[gaedduck]

I may be able to tell you in different point of view.
These days, compliers are getting better. so when you write i=i+1,
they recognize and change to i++;
so the problem is what compiler you will use.

Anyway, if the compiler is bad enough not to change i=i+1 to i++ and
cpu was old, you can see different machine instructions.
machine instructions depend on the cpu.
However, I think these days that is not a thing concerned.
That's like memory leak in C++ , which you don't have to concern in
Java.


Happy programming

Regards,

Namh

 

[Victor Bazarov]

I may be able to tell you in different point of view.
These days, compliers are getting better. so when you write i=i+1,
they recognize and change to i++;

It should actually change it to ++i.

so the problem is what compiler you will use.

Anyway, if the compiler is bad enough not to change i=i+1 to i++ and
cpu was old, you can see different machine instructions.
machine instructions depend on the cpu.
However, I think these days that is not a thing concerned.

It's not really the matter of "these days" or "some other days". It's
the matter of how big that difference is relative to the rest of the
program's execution time.

That's like memory leak in C++ , which you don't have to concern in
Java.

Why in hell did you have to bring in Java?

V

 

[gaedduck]

Why in hell did you have to bring in Java?

just i wanna say you don't have to concern about which will use among i
++ and i=i+1 if the compiler can optimize your source code.