About += and ++

[s0suk3]

I'm new to C and having doubt about the += and ++ operators. Writing
'i += 1' causes the same effect on 'i' as writing '++i' (or 'i++', but
the fetched value will be different). But since 'i += 1' is rather
equivalent to 'i = i + 1', then it is a reassignment, right? So, is
writing '++i' or 'i++' also a reassignment? What is the compiler doing
internally to increment the value in that case? Or is that
implementation-defined behavior?

Thanks,
Sebastian

 

[Richard Tobin]

I'm new to C and having doubt about the += and ++ operators. Writing
'i += 1' causes the same effect on 'i' as writing '++i' (or 'i++', but
the fetched value will be different). But since 'i += 1' is rather
equivalent to 'i = i + 1', then it is a reassignment, right? So, is
writing '++i' or 'i++' also a reassignment?

Yes, all of them assign new values to i. As statements, i+=1, i++,
and ++i, are all equivalent to i=i+1, and the compiler can (and
probably will) implement them all identically.

As you note, i++ is different when used within another expression.

-- Richard

 

[Chris Dollin]

I'm new to C and having doubt about the += and ++ operators. Writing
'i += 1' causes the same effect on 'i' as writing '++i' (or 'i++', but
the fetched value will be different).
Yes.

But since 'i += 1' is rather equivalent to 'i = i + 1', then it
is a reassignment, right?

Well, it's an assignment; nothing special about it, unless you
mean something special. Do you?

So, is writing '++i' or 'i++' also a reassignment?

It updates `i` -- it assigns it a new value. If that qualifies
as a reassignment, yes.

What is the compiler doing internally to increment the value
in that case?

It's generating code to increment the variable.

Or is that implementation-defined behavior?

No; it's implementation-specific. ("Implementation-defined" is a
technical term of the C standard, meaning "the implementation must
do something about X /and tell you what it does/". Implementation-
specific isn't a term of the Standard; I just mean that the
implementation does whatever it does and isn't obliged to tell you
what that is.)

Some machines (eg PDP-11) have fancy "increment" instructions
which will add 1 to a register (or even a memory location).
Other machines have to use their ordinary "add" instruction with
an operand of literal-one (eg ARM, in regsisters). Yet other
machines might need to use an add-register instruction after
loading one of the registers with the value 1.

It All Depends.

 

[santosh]

I'm new to C and having doubt about the += and ++ operators. Writing
'i += 1' causes the same effect on 'i' as writing '++i' (or 'i++', but
the fetched value will be different).

Yes. But the += notation allows you to add any arbitrary value to 'i'.
The increment operators always add one.

But since 'i += 1' is rather
equivalent to 'i = i + 1', then it is a reassignment, right? So, is
writing '++i' or 'i++' also a reassignment?

In an abstract sense yes. But the compiler may or may not emit the same
instructions for i += 1 versus ++i.

What is the compiler doing
internally to increment the value in that case? Or is that
implementation-defined behavior?

It's completely implementation defined as to the correspondance between
these statements and their object code instructions. The increment and
decrement operators were introduced so that some implementations could
take advantage of more efficient instructions (INC and DEC) for them in
comparison to a generic ADD or SUB instruction. What actually happens
depends on the characteristics of your system and your compiler's
optimisation settings.

 

[santosh]

Yes. But the += notation allows you to add any arbitrary value to 'i'.
The increment operators always add one.


In an abstract sense yes. But the compiler may or may not emit the
same instructions for i += 1 versus ++i.


It's completely implementation defined as to the correspondance
between these statements and their object code instructions.

Well, having seen Chris Dollin's post I feel obliged to point out that
my use of the term "implementation defined" above is incorrect. See
Chris's post for details.

<snip rest>

 

[Antoninus Twink]

Some machines (eg PDP-11) have fancy "increment" instructions
which will add 1 to a register (or even a memory location).

Some rather common machines have fancy "increment" instructions, but
nonetheless the manufacturer advises optimizing compiler writers to use
add *,0x1 instead...

Extract from <http://www.intel.com/design/processor/manuals/248966.pdf>:

Assembly/Compiler Coding Rule 32. INC and DEC instructions should be
replaced with ADD or SUB instructions, because ADD and SUB overwrite all
flags, whereas INC and DEC do not, therefore creating false dependencies
on earlier instructions that set the flags.

 

[Antoninus Twink]

But the compiler may or may not emit the same instructions for i += 1
versus ++i.

Can you name a compiler that doesn't?

 

[Richard Tobin]

Assembly/Compiler Coding Rule 32. INC and DEC instructions should be
replaced with ADD or SUB instructions, because ADD and SUB overwrite all
flags, whereas INC and DEC do not, therefore creating false dependencies
on earlier instructions that set the flags.

In some cases it can be useful to have flags preserved, but perhaps
compilers are not yet sophisticated enough to take advantage of that
(or rather, it's rare enough that it's not worth putting the effort
of making them handle the added complexity).

-- Richard

 

[Richard]

Can you name a compiler that doesn't?

It has become increasingly clear that Santosh merely posts "clique
smoothing" posts to increase his headline space. It is far easier to say
"possibly" than to provide any concrete answer which actually HELPS a
noob struggling with one single system. I am still astonished as to how
the regs have hijacked this group to exclude real world C questions and
examples.

Fortunately in my recent absence I see some of the regs have softened
their approach a little while the usual suspects have tightened up more
and others (read "Chuck" and "Default User") become more ridiculous with
every contribution they make.

 

[santosh]

It has become increasingly clear that Santosh merely posts "clique
smoothing" posts to increase his headline space. It is far easier to
say "possibly" than to provide any concrete answer which actually
HELPS a noob struggling with one single system.

In this case the OP did not specify any particular system. To quote him:

"What is the compiler doing internally to increment the value in that
case? Or is that implementation-defined behavior?"

So how would you have answered? If you have a better answer, why not
post it?

<snip>

 

[Willem]

santosh wrote:
) In an abstract sense yes. But the compiler may or may not emit the same
) instructions for i += 1 versus ++i.

The compiler may or may not emit the same instructions
for i += 1 versus i += 1,
this has nothing to do with the ++i versus i += 1 issue.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Stephen Sprunk]

I'm new to C and having doubt about the += and ++ operators. Writing
'i += 1' causes the same effect on 'i' as writing '++i' (or 'i++', but
the fetched value will be different). But since 'i += 1' is rather
equivalent to 'i = i + 1', then it is a reassignment, right? So, is
writing '++i' or 'i++' also a reassignment? What is the compiler doing
internally to increment the value in that case? Or is that
implementation-defined behavior?

A major part of it is historical. In the early days of C, computer time
was far more expensive that programmer time, so compilers didn't
optimize much (if at all); even modern compilers often don't optimize by
default. Some constructs were known to be "faster" because the compiler
could easily use a simpler instruction for "++i" than for "i+=1" or
"i=i+1". Each syntax translated directly into machine instructions, so
the programmer could take advantage of those "easy" optimizations when
they applied.

Today, of course, all of those constructs will yield the exact same code
if they have the same meaning when a modern optimizing compiler is used.

Another major part of it is laziness. "++i" obviously takes less typing
than "i=i+1", and takes less space to store in source form as well.
When you get to more complicated idioms, like "while (*i++ = *j++);" vs
"do { *i=*j; i=i+1; j=j+1; } while (*j);", the space savings gets
significant, as does readability. Such things appear over and over in
most programs, so it's normal that a language that "evolved" (as opposed
to one that was "designed") would incorporate features to make the
programmer's life easier for common tasks.

S

 

[Ben Bacarisse]

... When you get to more complicated idioms, like "while (*i++ =
*j++);" vs "do { *i=*j; i=i+1; j=j+1; } while (*j);", the space
savings gets significant, as does readability.

Note that they do different things. The "vs" suggests that they are
alternatives.

 

[Flash Gordon]

Malcolm McLean wrote, On 14/06/08 10:40:

That terse strcpy() seems to have driven a lot of C grammar.

I suspect it was not done to implement strcpy, it is merely that strcpy
is used as a common example.

However generally you write strcpy() once, if embedded, or never, on a
hosted implementation.

Stephen never said that you implement strcpy more than one, he said that
you get similar things over and over again. Similar is very different to
identical.

 

[Richard Tobin]

Did you mean i++ in one of those?

I *think* he was pointing out that a compiler doesn't even have to
generate the same code for two instances of the very same expression,
so whether it generates the same code for two different expressions
doesn't tell us much. But I could be wrong.

-- Richard

 

[Willem]

Richard Tobias wrote:
) In article <[email protected]>,
)
)>> The compiler may or may not emit the same instructions
)>> for i += 1 versus i += 1,
)>> this has nothing to do with the ++i versus i += 1 issue.
)
)>Did you mean i++ in one of those?
)
) I *think* he was pointing out that a compiler doesn't even have to
) generate the same code for two instances of the very same expression,
) so whether it generates the same code for two different expressions
) doesn't tell us much. But I could be wrong.

Spot on. I thought that was obvious from the (snipped) bit
I was replying to.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Richard Tobin]

Richard Tobias wrote:

Um, why did you change my name?

-- Richard

 

[Willem]

Richard Tobin wrote:
) In article <[email protected]>,
)>Richard Tobias wrote:
)
) Um, why did you change my name?

Oh sorry.. My posting software just displays the first name, but because
there are so many Richards in this group I decided to add (what I thought)
was your last name. I didn't mean anything by it, just a typo.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[David Thompson]

(e-mail address removed) wrote:

Some machines (eg PDP-11) have fancy "increment" instructions
which will add 1 to a register (or even a memory location).

I wouldn't call that 'fancy'. Maybe 'specialized'. Another example
probably(!) more familiar to people today is x86.

Other machines have to use their ordinary "add" instruction with
an operand of literal-one (eg ARM, in regsisters). Yet other

Or (slightly different) an add-immed insn with operand 1.

machines might need to use an add-register instruction after
loading one of the registers with the value 1.

Some also can add a small integer by (ab?)using effective-address
calculation, sometimes faster than an explicit ADD or even INC.

None of which alters your point that this is implementation (and
mostly target) dependent.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[John Bode]

Can you name a compiler that doesn't?

Can you state with absolute certainty that all C compilers everywhere
do? In all possible situations?