++i vs i++

[asm]

Hi All,

I would like to know when ++i should be used instead of i++ and vice versa.
Some code examples would be of help.

Does it really matter for assignments?

Thanks,
Arut

 

[Joona I Palaste]

Hi All,

I would like to know when ++i should be used instead of i++ and vice versa.
Some code examples would be of help.

Does it really matter for assignments?

Yes it matters. Consider j=++i and j=i++. In both cases i gets
incremented by one. However, the value of j is one more in the former
case than in the latter case.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"'It can be easily shown that' means 'I saw a proof of this once (which I didn't
understand) which I can no longer remember'."
- A maths teacher

 

[Chris Dollin]

I would like to know when ++i should be used instead of i++ and vice
versa.

Use ++i when you want the incremented value of i, and i++ when you
want the original value of i.

If you don't care which value you get, use either (although then I
switch to `i += 1`).

Does it really matter for assignments?

Yes, it really matters.

 

[Nicolas Pavlidis]

Hi All,

I would like to know when ++i should be used instead of i++ and vice versa.
Some code examples would be of help.

In terms of speed there is a difference. If you look at iterators:
They are highlevel objects that support the ++ in post(i++) and
prefix(++i) form, but for the postfiz form the hole object needs to be
copied two times, one time for storing the old value and another tie for
returning the old value.

IMHO if you don't need the behaviour of the postfix form, use the prefix
form.

Kind regrads,
Nicolas

 

[Joona I Palaste]

In terms of speed there is a difference. If you look at iterators:
They are highlevel objects that support the ++ in post(i++) and
prefix(++i) form, but for the postfiz form the hole object needs to be
copied two times, one time for storing the old value and another tie for
returning the old value.

This is an implementation detail and not mandated by the standard. The
compiler may implement the operators in any way it wants as long as the
result is the same as the standard defines.

 

[Michael Mair]

Hi Nicolas,

In terms of speed there is a difference. If you look at iterators:
They are highlevel objects that support the ++ in post(i++) and
prefix(++i) form, but for the postfiz form the hole object needs to be
copied two times, one time for storing the old value and another tie for
returning the old value.

IMHO if you don't need the behaviour of the postfix form, use the prefix
form.

<OT>
It depends. If for example the processor has a register reserved
for the stack pointer and a rather small instruction set, then it is
possible that only postincrement and predecrement are built-in,
as they are entirely sufficient.

As it was some years ago and only a couple of weeks' pastime, I am not
exactly sure but I think I recall that for one of the M68...
processors.
</OT>

Apart from that assembler stuff, most compilers nowadays are
sufficiently "intelligent" to use the same code for the three
statements
i++;
++i;
i+=1;
when you are obviously not interested in any side effects.


Cheers
Michael

 

[Richard Bos]

In terms of speed there is a difference. If you look at iterators:
They are highlevel objects that support the ++ in post(i++) and
prefix(++i) form, but for the postfiz form the hole object needs to be
copied two times, one time for storing the old value and another tie for
returning the old value.

Erm... bullshit. This is comp.lang.c, not comp.lang.++c.

Richard

 

[Joona I Palaste]

Erm... bullshit. This is comp.lang.c, not comp.lang.++c.

^^^

Heh. I wish I had thought of that.

 

[Dan Pop]

I would like to know when ++i should be used instead of i++ and vice versa.
Some code examples would be of help.

You don't need any code examples, once you understand the difference
between the prefix increment and the postfix increment operator.

Being operators, their evaluation must yield a value. The postfix
increment operator yields the value of its operand. The prefix increment
operator yields the incremented value of its operand. As a *side effect*,
both operators increment the value of their operand, at some, unspecified,
point before the next sequence point.

When they are used exclusively for their side effects (their value
is discarded), it doesn't matter which operator is used.

Does it really matter for assignments?

The above should answer this question.

Dan

 

[Malcolm]

I would like to know when ++i should be used instead of i++ and vice versa.
Some code examples would be of help.

Does it really matter for assignments?

In C, the form i++ is idiomatic. The form ++i really shouldn't be used. It
increments i before calculating the value of i, which is almost never
required. Even if it would be handy, its use will confuse maintaining
programmers. If ++i would make an expression more compact, break it down
into two lines instead.

However in C++, because of a quirk of the language, the form ++C is faster
than the form C++ for overloaded types with complex logic. Here the ++C form
should be used.

 

[Minti]

Hi All,

I would like to know when ++i should be used instead of i++ and vice versa.
Some code examples would be of help.

int x,
y;
int i = 5;
x = i++;
y = ++i;

Does it really matter for assignments?

Not sure, I never submit my assignments on time.

 

[Christopher Benson-Manica]

In C, the form i++ is idiomatic. The form ++i really shouldn't be used. It
increments i before calculating the value of i, which is almost never
required. Even if it would be handy, its use will confuse maintaining
programmers. If ++i would make an expression more compact, break it down
into two lines instead.

How will ++i confuse anyone who knows what s/he is doing? I'm far
from an expert, and I certainly don't find it confusing.

 

[Eric Sosman]

In C, the form i++ is idiomatic. The form ++i really shouldn't be used. It
increments i before calculating the value of i, which is almost never
required. Even if it would be handy, its use will confuse maintaining
programmers. If ++i would make an expression more compact, break it down
into two lines instead.

Have you been smoking those funny cigarettes again, Malcolm? It's
unlike you to make such idioTmatic remarks ... I'd be interested to
know what other C operators you think "shouldn't be used," and on what
grounds, however shaky. I'm sure it'd be amusing.

However in C++, because of a quirk of the language, the form ++C is faster
than the form C++ for overloaded types with complex logic. Here the ++C form
should be used.

Another (and equally compelling) reason to avoid both the `++c' and
`c++' forms is that they're syntax errors in Pascal.

 

[pete]

In C, the form i++ is idiomatic.
The form ++i really shouldn't be used.

I disagree.

It increments i before calculating the value of i,
which is almost never required.

No it doesn't.
The expressions (++i) and (i++) have values and side effects.
The side effect is that the value in i is increased by 1.
The value of (i++) is the value before the increment and
the value of (++i) is the value after the increment,
but whether the increment or the evaluation takes place first,
is not part of C.

Even if it would be handy, its use will confuse maintaining
programmers.

Does it really confuse you?

If ++i would make an expression more compact,
break it down into two lines instead.

However in C++, because of a quirk of the language,
the form ++C is faster than the form C++
for overloaded types with complex logic.

You're off topic and I don't believe you.

Here the ++C form should be used.

I disagree.

 

[Keith Thompson]

Malcolm wrote: [...]

However in C++, because of a quirk of the language,
the form ++C is faster than the form C++
for overloaded types with complex logic.

You're off topic and I don't believe you.

Here the ++C form should be used.

I disagree.

Please note the '[OT]' tag in the subject. I'm discussing this here
partly to contrast C++ vs. C.

In C++, the "++" operator can be overloaded so it invokes a
user-defined function; the meaning of "increment" is determined by the
function itself, and can involve arbitrarily complex computations.

For x++, the result is the value of x before it's "incremented". In
some cases, that means that previous value of x has to be saved
somewhere, then x is "incremented", then the saved value becomes the
value of the expression. For a user-defined type, this can introduce
significant overhead, and it can be difficult for the compiler to
optimize it away. For ++x, the value of x is "incremented" and the
result is the new value of x; the old value doesn't have to be saved.

There may also be some differences between C and C++ regarding whether
the result is an lvalue; I don't remember the details.

For C, neither x++ nor ++x can invoke a user-defined function, so the
compiler is better able to optimize the expression. For any decent C
compiler, there should be no difference between x++ and ++x if the
result is discarded (e.g., if it's used as an expression statement).
(The same is probably true in C++ for predefined types.) If the
result *is* used, x++ and ++x are semantically different; choosing the
wrong one will, at best, give you a wrong answer more quickly.

 

[Derrick Coetzee]

I would like to know when ++i should be used instead of i++ and vice versa.
Some code examples would be of help.

As a practical matter, you should almost never use either of these
except on a line by itself, in which case it doesn't matter. The
reasoning behind this claim is that it's difficult to read statements
using these operators and they can always be pulled out into a separate
statement. Here are some examples of pulling them out:

*p1++ = *p2++;
....becomes...
*p1 = *p2;
p1++; p2++;

while(*++p) { ... }
....becomes...
for(p++; *p; p++) { ... }

x = 2 + f(*p++);
....becomes...
temp = 2 + f(*p);
p++;
x = temp;

I would claim that the revised examples above are all clearer than their
briefer counterparts. Not even a novice has to stop and think about what
order things are happening in; the lexical order reflects the execution
order. Remember, your code should be boring and obvious, not sacrificing
clarity for brevity. Also don't forget that increments are a quick way
to get yourself into trouble with undefined behavior if you're not
careful, as in:

x = *p++ + *p++;

This yields UB. What was probably intended here was the straightforward:

x = *p;
p++;
x += *p;
p++;

 

[Method Man]

while(*++p) { ... }

...becomes...
for(p++; *p; p++) { ... }

Personally, I find the first one easier to read.

Remember, your code should be boring and obvious, not sacrificing
clarity for brevity.

It's all subjective to who the code's audience is. To experienced
programmers, operators like '++' become second nature. And consider:

(*p).
vs
p->

Which is more readable and which is used more often?

 

[pete]

For any decent C
compiler, there should be no difference between x++ and ++x if the
result is discarded (e.g., if it's used as an expression statement).
(The same is probably true in C++ for predefined types.)

I'd like to point out that the expression (i-- != 1)
is semantically equal to (--i != 0), (except where i is a pointer)
meaning that any implementation might translate those two
expressions identically. I would be more likely to use the second
expression in source code, than the first.

 

[Flash Gordon]

I'd like to point out that the expression (i-- != 1)
is semantically equal to (--i != 0), (except where i is a pointer)
meaning that any implementation might translate those two
expressions identically.

No they aren't. In one you are comparing against the value i has BEFORE
it is decremented and in the other you are comparing against the value i
has AFTER it is decremented.

I would be more likely to use the second
expression in source code, than the first.

I that case I suspect that you would misinterpret what the first form is
doing.

 

[Derrick Coetzee]

It's all subjective to who the code's audience is. To experienced
programmers, operators like '++' become second nature.

Keep in mind that not every programmer who maintains your code may be an
expert, or be an expert who is particular lucid at the time (under high
stress, low on sleep, hangover, etc.) To experienced programmers,
assembly language is second nature, but that doesn't mean we prefer it.

And consider:
(*p). vs p->
Which is more readable and which is used more often?

The important thing is that lexical order reflects execution order. In
this case you can read "p->" as a single conceptual operation with
chooses a member from the object p refers to. The choice of * as a
prefix rather than a postfix operator is arbitrary (although in this
case needed to automatically parse things correctly). This is
effectively a local transformation, unlike ++, which can potentially be
transmitted across an arbitrarily long string of tokens, as in this example:

b = a++ + /* one-million token expression */;