for loop i++ or ++i

[Brian]

It's a minor thing, but I'm confused on the increment operator in a for loop.

I think most usually write:

for (int i = 0; i < something; i++)
{
....
}

But, in my book (from MSPress) it shows:

for (int i; i < something; ++i)
{
....
}
From what I remember in my readings, the ++i is supposed to be faster, performance
wise.

As far as results, they both seem to do the same thing in a loop.
In my tests, of "for (int i = 0, i < 9, ++i OR i++)", both loops iterated
from 0 to 9.

But, in reading up on the increment operator on MSDN:

++i = The result of the operation is the value of the operand after it has
been incremented.

i++ = The result of the operation is the value of the operand before it has
been incremented.

This doesn't seem to make sense. If ++i returns the value after it has been
incremented, then if i was initilized to 0, should the first loop in the
for loop have i = 1????

--Brian

[Michael C#]

Think of your for loop in these terms. It's roughly equivalent to a while
loop and an assignment statement:

int i = 0;
while (i < 9)
{
...
i++;
}

OR

int i = 0;
while (i < 9)
{
...
++i;
}

As you can see, the increment operator occurs at the end of the while loop.
The effects on placement of ++ is more readily apparent in this example:

int i = 0;
// Assigns the value of i to j
// THEN increments i
int j = i++;
Console.WriteLine(j);

i = 0;
// Increments i, then assigns the
// value if i to j
j = ++i;
Console.WriteLine(j);

Thanks.

"Brian" <fa**@email.com> wrote in message
news:40********************@news.microsoft.com...

It's a minor thing, but I'm confused on the increment operator in a for
loop.

I think most usually write:

for (int i = 0; i < something; i++)
{
...
}

But, in my book (from MSPress) it shows:

for (int i; i < something; ++i)
{
...
}
From what I remember in my readings, the ++i is supposed to be faster,
performance wise.

As far as results, they both seem to do the same thing in a loop.
In my tests, of "for (int i = 0, i < 9, ++i OR i++)", both loops iterated
from 0 to 9.

But, in reading up on the increment operator on MSDN:

++i = The result of the operation is the value of the operand after it has
been incremented.

i++ = The result of the operation is the value of the operand before it
has been incremented.

This doesn't seem to make sense. If ++i returns the value after it has
been incremented, then if i was initilized to 0, should the first loop in
the for loop have i = 1????

--Brian

[Bruno Jouhier [MVP]]

There is a difference between i++ and ++i if you **use** the value of the
expression. For example:
int j = i++;
and
int j = ++i;
will assign different values to j.

But if you put the i++ or ++i expression in the 3rd clause of the for
construct, you get a simple statement and the value that it produces in
**not used** for anything. So, there won't be any difference, not even in
performance, because the compiler will simply generate an increment
instruction and will not worry about the value produced by the expression.

Bruno

"Brian" <fa**@email.com> a écrit dans le message de news:
40********************@news.microsoft.com...

It's a minor thing, but I'm confused on the increment operator in a for
loop.

I think most usually write:

for (int i = 0; i < something; i++)
{
...
}

But, in my book (from MSPress) it shows:

for (int i; i < something; ++i)
{
...
}
From what I remember in my readings, the ++i is supposed to be faster,
performance wise.

As far as results, they both seem to do the same thing in a loop.
In my tests, of "for (int i = 0, i < 9, ++i OR i++)", both loops iterated
from 0 to 9.

But, in reading up on the increment operator on MSDN:

++i = The result of the operation is the value of the operand after it has
been incremented.

i++ = The result of the operation is the value of the operand before it
has been incremented.

This doesn't seem to make sense. If ++i returns the value after it has
been incremented, then if i was initilized to 0, should the first loop in
the for loop have i = 1????

--Brian

[Brian]

Thanks,

That makes sense.

B

Think of your for loop in these terms. It's roughly equivalent to a
while loop and an assignment statement:

int i = 0;
while (i < 9)
{
...
i++;
}
OR

int i = 0;
while (i < 9)
{
...
++i;
}
As you can see, the increment operator occurs at the end of the while
loop. The effects on placement of ++ is more readily apparent in this
example:

int i = 0;
// Assigns the value of i to j
// THEN increments i
int j = i++;
Console.WriteLine(j);
i = 0;
// Increments i, then assigns the
// value if i to j
j = ++i;
Console.WriteLine(j);
Thanks.

"Brian" <fa**@email.com> wrote in message
news:40********************@news.microsoft.com...

It's a minor thing, but I'm confused on the increment operator in a
for loop.

I think most usually write:

for (int i = 0; i < something; i++)
{
...
}
But, in my book (from MSPress) it shows:

for (int i; i < something; ++i)
{
...
}
From what I remember in my readings, the ++i is supposed to be
faster, performance wise.

As far as results, they both seem to do the same thing in a loop.
In my tests, of "for (int i = 0, i < 9, ++i OR i++)", both loops
iterated
from 0 to 9.
But, in reading up on the increment operator on MSDN:

++i = The result of the operation is the value of the operand after
it has been incremented.

i++ = The result of the operation is the value of the operand before
it has been incremented.

This doesn't seem to make sense. If ++i returns the value after it
has been incremented, then if i was initilized to 0, should the first
loop in the for loop have i = 1????

--Brian

[Flip]

> From what I remember in my readings, the ++i is supposed to be faster,

performance

I too have read about this performance gain when you use the
pre-incrementor. However, everyone I've talked to since has said it was
hogwash. Unfortunately I don't have the article handy for reference. :<
And that was when I was learning C++, so maybe in the C# world this
performance gain has been incorporated in/out of the JIT and may no longer
be applicable?

Can any JIT gurus comment?

[Helge Jensen]

Flip wrote:

I won't comment on the semantic equivalence of "++i" and "i++" in
for-loops, other posters have done that, but try to explain *why*
postfix increment may be considered "more expensive".

Try to think of is as:

class Foo {
Foo(Foo other) { this.state = other.state; } // copy-constructor
private void increment();
static Foo prefix_increment(Foo foo);
static Foo postfix_increment(Foo foo);
}

Now, prefix_increment should return a Foo in an incremented state, and
leave the "foo" argument in an incremented state -- how convinient:

static Foo prefix_increment(Foo foo) { foo.increment(); return foo; }

But what about the postfix one? well it needs to return an object in the
same state as "foo", but increment the state of "foo", there really only
is one solution:

static Foo postfix_increment(Foo foo) {
Foo ret = new Foo(foo);
foo.increment();
return ret;
}

This requires copying the state of foo to another Foo-instance!

C++ compilers are quite good at removing this overhead -- so there
really isn't much difference, except that "++i" will never incur the
overhead. If i is an "int" i doubt *very* much that you would ever see
any performance difference.

Especially, compilers can often simply the code around:

f(i++);

Is intentionally (except in the process of overloading resolution --
atleast in c++, dunno about C#) equivalent to

f(i); ++i;

But the latter form may be inconvinient for the programmer: it is not
one statement, and therefore fits badly into sytax that requires a block
or single statement: if, for, ... requiering another set of braces (and
if you are using the on-crack convention of braces on newlines: 2 more
lines of confusion :)

Can any JIT gurus comment?

I am definatly not a JIT guru, but I have crossed swords with a lot of
c++ in my time :)

Anyway, if you ever have a performance-problem due to
postfix-incrementing-by-convention I'd like to see it.

But, when you know the issue, you tend to write "++i" instead of "i++"
-- just because it feels better and doesn't cost a thing.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Michael C#]

"Flip" <[remove_me]ph******@hotmail.com> wrote in message
news:uR**************@TK2MSFTNGP09.phx.gbl...

From what I remember in my readings, the ++i is supposed to be faster,
performance

I too have read about this performance gain when you use the
pre-incrementor. However, everyone I've talked to since has said it was
hogwash. Unfortunately I don't have the article handy for reference. :<
And that was when I was learning C++, so maybe in the C# world this
performance gain has been incorporated in/out of the JIT and may no longer
be applicable?

Can any JIT gurus comment?

Can't speak to JIT on C# for that one, but in x86 Assembler-speak, you're
looking at roughly this (in these examples -- very, very simplified -- AX
represents a register and [i] and [j] represent memory locations for i and j
integer variables):

"j = ++i" would roughly be equivalent to:

MOV AX, [i]
INC AX
MOV [i], AX
MOV [j], AX

"j = i++" would be roughly equivalent to:

MOV AX, [i]
MOV [j], AX
INC AX
MOV [i], AX

Although the compiler might be able to further optimize to take advantage of
various other instructions, we're looking at basically the same instructions
just in a slightly different order. And this is just for an integer data
type. For other data types, especially objects, there's a lot more moving
and copying of data between memory locations than with a standard integer.
Helge spoke to that.

So basically, for an integer data type, there's really no difference between
the instructions ++i and i++ generate - just the order they are generated
in. So your performance should not be affected one way or the other
depending on which you use; the results of your calculations, however, can
be affected wildly; so use them in calculations carefully.

---

As a side note: For a compiler that didn't optimize well, "i = i + 1; j =
i" might end up generating something like this:

MOV AX, [i]
ADD AX, 1
MOV [i], AX
MOV [j], AX

This would be less efficient because the non-optimizing compiler translated
our code literally, and replaced i + 1 with an ADD instruction. The ADD
instruction takes up more memory and executes more slowly than the INC
instruction. Most compilers are smart enough to convert j = i + 1 to an INC
instruction, however.