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
27  1416 
In article <48**********************************@d45g2000hsc. googlegroups.com>,
<s0****@gmail.comwrote:
>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
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963) s0****@gmail.com wrote:
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.
--
"The wizard seemed quite willing when I talked to him." /Howl's Moving Castle/
Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England s0****@gmail.com wrote:
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 wrote: s0****@gmail.com wrote:
>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.
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>
On 13 Jun 2008 at 10:27, Chris Dollin wrote:
s0****@gmail.com wrote:
>What is the compiler doing internally to increment the value
in that case?
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.
On 13 Jun 2008 at 10:27, santosh wrote:
But the compiler may or may not emit the same instructions for i += 1
versus ++i.
Can you name a compiler that doesn't?
In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>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
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)
Antoninus Twink <no****@nospam.invalidwrites:
On 13 Jun 2008 at 10:27, santosh wrote:
>But the compiler may or may not emit the same instructions for i += 1
versus ++i.
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.
Richard wrote:
Antoninus Twink <no****@nospam.invalidwrites:
>On 13 Jun 2008 at 10:27, santosh wrote:
>>But the compiler may or may not emit the same instructions for i +=
1 versus ++i.
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.
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>
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
santosh said:
Richard wrote:
<snip>
>>
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?
If he had a better answer, presumably he /would/ have posted it. We may safely
deduce that he doesn't have a better answer.
It's up to you, obviously, but you might want to reflect on the fact that he's
being what Dann used to call a "whinging twit". His posts (or at least the
ones that I see quoted by others) are almost invariably complaints about
other posters - which is sheer hypocrisy on his part. Do you really have the
time to waste on replying to him?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
santosh wrote:
Richard wrote:
>Antoninus Twink <no****@nospam.invalidwrites:
>>santosh wrote:
But the compiler may or may not emit the same instructions for
i += 1 versus ++i.
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.
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?
Why are you responding to those two known trolls?
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com ** s0****@gmail.com wrote:
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
Stephen Sprunk <st*****@sprunk.orgwrites:
>... 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.
--
Ben.
"Stephen Sprunk" <st*****@sprunk.orgwrote in message
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.
That terse strcpy() seems to have driven a lot of C grammar.
However generally you write strcpy() once, if embedded, or never, on a
hosted implementation.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
Malcolm McLean wrote, On 14/06/08 10:40:
>
"Stephen Sprunk" <st*****@sprunk.orgwrote in message
>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.
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.
--
Flash Gordon
Willem <wi****@stack.nlwrites:
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?
Best,
Tony
In article <86************@tourifreet.wellworld>,
A. F. McClelland <t_**********@btinternet.comwrote:
>Willem <wi****@stack.nlwrites:
>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.
-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)
Richard Tobias wrote:
) In article <86************@tourifreet.wellworld>,
) A. F. McClelland <t_**********@btinternet.comwrote:
)
)>Willem <wi****@stack.nlwrites:
)>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
In article <sl********************@snail.stack.nl>,
Willem <wi****@stack.nlwrote:
>Richard Tobias wrote:
Um, why did you change my name?
-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)
Richard Tobin wrote:
) In article <sl********************@snail.stack.nl>,
) Willem <wi****@stack.nlwrote:
)>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
Willem wrote:
Richard Tobias wrote:
>A. F. McClelland <t_**********@btinternet.comwrote:
>>Willem <wi****@stack.nlwrites:
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.
Rather hard to connect it with snipped quotations. However, the
context of the statement obviously can affect the optimum code to
use.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
On Fri, 13 Jun 2008 11:27:29 +0100, Chris Dollin <ch**********@hp.com>
wrote: s0****@gmail.com wrote:
What is the compiler doing internally to increment the value
in that case?
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
On Jun 13, 5:38 am, Antoninus Twink <nos...@nospam.invalidwrote:
On 13 Jun 2008 at 10:27, santosh wrote:
But the compiler may or may not emit the same instructions for i += 1
versus ++i.
Can you name a compiler that doesn't?
Can you state with absolute certainty that all C compilers everywhere
do? In all possible situations?
John Bode <jf********@gmail.comwrites:
On Jun 13, 5:38 am, Antoninus Twink <nos...@nospam.invalidwrote:
>On 13 Jun 2008 at 10:27, santosh wrote:
But the compiler may or may not emit the same instructions for i += 1
versus ++i.
Can you name a compiler that doesn't?
Can you state with absolute certainty that all C compilers everywhere
do? In all possible situations?
Of course not, in the same way I can not be assured that the standard
means the same thing to some language lawyers in another state. But
meanwhile in the real world where common sense applies ....
On Jun 24, 10:31 am, Richard<rgr...@gmail.comwrote:
John Bode <jfbode1...@gmail.comwrites:
On Jun 13, 5:38 am, Antoninus Twink <nos...@nospam.invalidwrote:
On 13 Jun 2008 at 10:27, santosh wrote:
But the compiler may or may not emit the same instructions for i += 1
versus ++i.
Can you name a compiler that doesn't?
Can you state with absolute certainty that all C compilers everywhere
do? In all possible situations?
Of course not, in the same way I can not be assured that the standard
means the same thing to some language lawyers in another state. But
meanwhile in the real world where common sense applies ....
In the "real world" where common sense applies, it's reasonable to
point out that not all compilers are guaranteed to behave the same way
for a given language construct (*especially* for the pre/post
increment operators). Normally that would be an uncontroversial
statement, but you and Twink are so eager to pounce on any perceived
instance of pedantry that you come off sounding like idiots.
On Fri, 13 Jun 2008 10:38:41 +0000, Antoninus Twink wrote:
On 13 Jun 2008 at 10:27, santosh wrote:
>But the compiler may or may not emit the same instructions for i += 1
versus ++i.
Can you name a compiler that doesn't?
Yes. Nils Weller's compiler (from <http://nwcc.sourceforge.net/>) doesn't
optimise at all, and generates different code for the two expressions in
the version I tried. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: eScrewDotCom |
last post by:
eScrew
Welcome to eScrew!
eScrew is eScrew and this is eScrew story. eScrew will tell you eScrew
story if you promise eScrew to consider eScrew story as joke. eScrew
story is very funny. eScrew...
|
by: Brandon J. Van Every |
last post by:
What's better about Ruby than Python? I'm sure there's something. What is
it?
This is not a troll. I'm language shopping and I want people's answers. I
don't know beans about Ruby or have...
|
by: eScrewDotCom |
last post by:
eScrew
Welcome to eScrew!
eScrew is eScrew and this is eScrew story. eScrew will tell you eScrew
story if you promise eScrew to consider eScrew story as joke. eScrew
story is very funny. eScrew...
|
by: Sarah Tanembaum |
last post by:
Beside its an opensource and supported by community, what's the fundamental
differences between PostgreSQL and those high-price commercial database (and
some are bloated such as Oracle) from...
|
by: eScrewDotCom |
last post by:
www.eScrew.com
eScrew
Welcome to eScrew!
eScrew is eScrew and this is eScrew story. eScrew will tell you eScrew
story if you promise eScrew to consider eScrew story as joke. eScrew
story is...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
