basic for loop question

[pauldepstein]

Is there any difference between

for(int i = 0; some condition; i++)
{....}

and

for(int i = 0; some condition; ++i) ?
{....}

It seems not, by some experimenting, but I thought it was worth
checking since j++ and ++j usually mean different things in the
language ++c .

Thanks a lot,

Paul Epstein

[Mateusz Loskot]

pa**********@att.net wrote:

Is there any difference between

for(int i = 0; some condition; i++)
{....}

and

for(int i = 0; some condition; ++i) ?
{....}

It seems not, by some experimenting, but I thought it was worth
checking since j++ and ++j usually mean different things in the
language ++c .

You mean difference in...performance, semantic,...?

Semantically, there is a difference because in the first case
temporary object is created.
There may or may not be difference in speed and performance. it depends
on C++ implementation you use, optimization, etc.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net

[keith]

On 25 Jan, 05:59, Mateusz Loskot <[e-mail]:

[e-mail] wrote:

Is there any difference between

for(int i = 0; some condition; i++)
{....}

and

for(int i = 0; some condition; ++i) ?
{....}

It seems not, by some experimenting, but I thought it was worth
checking since j++ and ++j usually mean different things in the
language ++c .

You mean difference in...performance, semantic,...?

Semantically, there is a difference because in the first case
temporary object is created.
There may or may not be difference in speed and performance. it depends
on C++ implementation you use, optimization, etc.

Generally speaking (and the FAQ book from Cline et al concurs:
Q23.08), one should use the prefix increment if the previous value of
the operand is discarded, as in the example above. The rationale is
that the postfix operator needs to make a copy of the operand,
increment the operand, then return the value of the copy; the prefix
operator merely needs to increment the operand and return its value.

[Lionel B]

On Fri, 25 Jan 2008 02:40:43 -0800, keith wrote:

On 25 Jan, 05:59, Mateusz Loskot <[e-mail]:

>[e-mail] wrote:

Is there any difference between

for(int i = 0; some condition; i++)
{....}

and

for(int i = 0; some condition; ++i) ? {....}

It seems not, by some experimenting, but I thought it was worth
checking since j++ and ++j usually mean different things in the
language ++c .

You mean difference in...performance, semantic,...?

Semantically, there is a difference because in the first case temporary
object is created.
There may or may not be difference in speed and performance. it depends
on C++ implementation you use, optimization, etc.

Generally speaking (and the FAQ book from Cline et al concurs: Q23.08),
one should use the prefix increment if the previous value of the operand
is discarded, as in the example above. The rationale is that the
postfix operator needs to make a copy of the operand, increment the
operand, then return the value of the copy; the prefix operator merely
needs to increment the operand and return its value.

Out of interest, does the standard mandate that the postfix version is
*required* to make a copy? Obviously it's not going to make any
difference for an int (and I'd expect an optimising compiler to generate
identical code here), but when incrementing an object with a non-trivial
copy constructor it potentially could make a difference.

--
Lionel B

[keith]

On 25 Jan, 11:05, Lionel B <[e-mail]:

On Fri, 25 Jan 2008 02:40:43 -0800, keith wrote:

Generally speaking (and the FAQ book from Cline et al concurs: Q23.08),
one should use the prefix increment if the previous value of the operand
is discarded, as in the example above. The rationale is that the
postfix operator needs to make a copy of the operand, increment the
operand, then return the value of the copy; the prefix operator merely
needs to increment the operand and return its value.

Out of interest, does the standard mandate that the postfix version is
*required* to make a copy? Obviously it's not going to make any
difference for an int (and I'd expect an optimising compiler to generate
identical code here), but when incrementing an object with a non-trivial
copy constructor it potentially could make a difference.

I doubt the standard has anything to say on the matter, but how else
would you increment the operand (whatever that might mean for the
object concerned), _and_then_ return the previous value?

[Joe Greer]

Lionel B <[e-mail] in news:fn**********@south.jnrs.ja.net:

>
Out of interest, does the standard mandate that the postfix version is
*required* to make a copy? Obviously it's not going to make any
difference for an int (and I'd expect an optimising compiler to generate
identical code here), but when incrementing an object with a non-trivial
copy constructor it potentially could make a difference.

The way I look at it is that ++i and i++ take the same number of keystrokes
to type and ++i better indicates what I mean (increment i and use that
value). That it has the side benefit of being more efficient without
relying on QOI is just a side benefit. In the case of user defined objects
with overloaded operator++, I am not sure how you could do it without
making a copy, but even if you could I don't think I would like to rely on
QOI to make that decision.

joe

[James Kanze]

On Jan 25, 6:24 am, [e-mail] wrote:

Is there any difference between

for(int i = 0; some condition; i++)
{....}

and

for(int i = 0; some condition; ++i) ?
{....}

Yes. One is what other people on the project are doing in
similar cases. The other is not.

It seems not, by some experimenting, but I thought it was
worth checking since j++ and ++j usually mean different things
in the language ++c .

The difference is in the returned value. In this case, the
returned value is being ignored.

There have been claims (and still are, by people who prefer
speculation to measurement) that the prefix version will be
faster for user defined types, like iterators. For this reason,
on a green fields project, it is probably simpler to choose
prefix notation, and avoid the arguments. If there is any
existing code, however, just use whatever it uses, and don't
worry about it.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Lionel B]

On Fri, 25 Jan 2008 04:58:18 -0800, keith wrote:

On 25 Jan, 11:05, Lionel B <[e-mail]:

>On Fri, 25 Jan 2008 02:40:43 -0800, keith wrote:

Generally speaking (and the FAQ book from Cline et al concurs:
Q23.08), one should use the prefix increment if the previous value of
the operand is discarded, as in the example above. The rationale is
that the postfix operator needs to make a copy of the operand,
increment the operand, then return the value of the copy; the prefix
operator merely needs to increment the operand and return its value.

Out of interest, does the standard mandate that the postfix version is
*required* to make a copy? Obviously it's not going to make any
difference for an int (and I'd expect an optimising compiler to
generate identical code here), but when incrementing an object with a
non-trivial copy constructor it potentially could make a difference.

I doubt the standard has anything to say on the matter, but how else
would you increment the operand (whatever that might mean for the object
concerned), _and_then_ return the previous value?

Sorry, I obviously didn't express myself very well... the situation I had
in mind is where the return value of postfix increment is *discarded*.
Then, is the compiler allowed *not* to make a copy of the object?

--
Lionel B

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-01-25 17:30, Lionel B wrote:

On Fri, 25 Jan 2008 04:58:18 -0800, keith wrote:

>On 25 Jan, 11:05, Lionel B <[e-mail]:

>>On Fri, 25 Jan 2008 02:40:43 -0800, keith wrote:

Generally speaking (and the FAQ book from Cline et al concurs:
Q23.08), one should use the prefix increment if the previous value of
the operand is discarded, as in the example above. The rationale is
that the postfix operator needs to make a copy of the operand,
increment the operand, then return the value of the copy; the prefix
operator merely needs to increment the operand and return its value.

Out of interest, does the standard mandate that the postfix version is
*required* to make a copy? Obviously it's not going to make any
difference for an int (and I'd expect an optimising compiler to
generate identical code here), but when incrementing an object with a
non-trivial copy constructor it potentially could make a difference.

I doubt the standard has anything to say on the matter, but how else
would you increment the operand (whatever that might mean for the object
concerned), _and_then_ return the previous value?

Sorry, I obviously didn't express myself very well... the situation I had
in mind is where the return value of postfix increment is *discarded*.
Then, is the compiler allowed *not* to make a copy of the object?

There is something called the "as if" rule (section 1.9 of the standard)
which basically says that as long as the observable behaviour of the
program during execution is the same as if things were done as described
in the standard then the program is conforming. So if you do not try to
make any use of the returned value then the compiler should be free to
do nothing except increment the value.

For an integer this should be simple but for user defined types the
compiler might have some trouble to decide how much of the code is
needed an what it can safely skip, which is why it is generally
recommended to use the prefix version.

--
Erik Wikström

[Rolf Magnus]

Joe Greer wrote:

Lionel B <[e-mail] in news:fn**********@south.jnrs.ja.net:

>>
Out of interest, does the standard mandate that the postfix version is
*required* to make a copy? Obviously it's not going to make any
difference for an int (and I'd expect an optimising compiler to generate
identical code here), but when incrementing an object with a non-trivial
copy constructor it potentially could make a difference.

The way I look at it is that ++i and i++ take the same number of
keystrokes to type and ++i better indicates what I mean (increment i and
use that value).

You don't use the value (at least not in the example the OP posted). You
discard it. So in that regard, both variants are the same. With ++i, you
discard the new value, with i++, you discard the old one.

[Rolf Magnus]

James Kanze wrote:

On Jan 25, 6:24 am, [e-mail] wrote:

>Is there any difference between

>for(int i = 0; some condition; i++)
{....}

>and

>for(int i = 0; some condition; ++i) ?
{....}

Yes. One is what other people on the project are doing in
similar cases. The other is not.

>It seems not, by some experimenting, but I thought it was
worth checking since j++ and ++j usually mean different things
in the language ++c .

The difference is in the returned value. In this case, the
returned value is being ignored.

There have been claims (and still are, by people who prefer
speculation to measurement) that the prefix version will be
faster for user defined types, like iterators. For this reason,
on a green fields project, it is probably simpler to choose
prefix notation, and avoid the arguments. If there is any
existing code, however, just use whatever it uses, and don't
worry about it.

Considering that - except for the potential difference in execution time -
there is no difference, why use the postfix version? If I definitely don't
gain anything from one solution, but might (even if chances are slim) gain
something from the other, then I use of course that one.

[James Kanze]

On Jan 26, 6:15 pm, Rolf Magnus <[e-mail]:

James Kanze wrote:

[...]

There have been claims (and still are, by people who prefer
speculation to measurement) that the prefix version will be
faster for user defined types, like iterators. For this reason,
on a green fields project, it is probably simpler to choose
prefix notation, and avoid the arguments. If there is any
existing code, however, just use whatever it uses, and don't
worry about it.

Considering that - except for the potential difference in
execution time - there is no difference, why use the postfix
version?

Typically, because it is the established coding convention where
you're working.

If I definitely don't gain anything from one solution, but
might (even if chances are slim) gain something from the
other, then I use of course that one.

Supposing all other things equal. They usually aren't. If your
shop has the established tradition of using the postfix op
(frequent, if for no other reason that that's what K&R did),
that's a very strong reason for using postfix---it requires (or
should require) significant motivation to change. And that
significant motivation isn't there.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]