Re: What the?

I find ++Variable much easier to read so I use it everywhere except on the rare occasion where I really want a post decrement (like in a subscript). Even then though I'd tend to split the operations up to make it easier to read. I guess I have a lot of faith in the optimizer :o)

Tom

"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message news:snd6r39hu2i2hma310ah9b7sbi18vn8okm@xxxxxxxxxx
On Wed, 13 Feb 2008 12:12:53 -0500, Joseph M. Newcomer
<newcomer@xxxxxxxxxxxx> wrote:

But the real question is not "does it have an extra line of C code in the function?" but
"does it generate any more code?" The ultimate test is by looking at the generated
machine code. If I weren't going to spend the entire afternoon in tax-mode, I try a few
tests to see what the real costs were for a set of STL iterators.
joe

At best, you will come up with an answer that applies to one compiler, one
set of compiler settings, and whatever classes you test. See my reply to
Giovanni for more reasons why this won't be the basis for any general
advice. Specifically, it matters if the compiler has the class definition
(or the functions are inline), which it will for STL classes, because
they're templates. If you do perform the test you described, be sure to
compare and contrast it with:

struct X
{
X& operator++();
X operator++(int);
};

void f1(X& x)
{
++x;
}

void f2(X& x)
{
x++;
}

*****

The C++ FAQ says:

[13.15] Which is more efficient: i++ or ++i?
http://www.parashift.com/c++-faq-lite/operator-overloading.html#faq-13.15
<q>
++i is sometimes faster than, and is never slower than, i++.
...
So if you're writing i++ as a statement rather than as part of a larger
expression, why not just write ++i instead? You never lose anything, and
you sometimes gain something. Old line C programmers are used to writing
i++ instead of ++i. E.g., they'll say, for (i = 0; i < 10; i++) .... Since
this uses i++ as a statement, not as a part of a larger expression, then
you might want to use ++i instead.
</q>

Lots of people apparently imprinted on i++ because that's what K&R did, but
there's no rational reason to cling to that preference in C++. I programmed
in C extensively for about 9 years before moving to C++, and while I always
wrote i++ per K&R, I instantly understood the C++ argument why ++i is
better when there's a choice, namely, "It never hurts, and it may help."

--
Doug Harrison
Visual C++ MVP

.

Relevant Pages

  • Library Design, the script kiddies nightmare.
    ... good across the board of assembler programming. ... With languages that have the capacity, libraries of reusable code make ... comes at a cost that some of the older assembler programmers will not ... The virtue of writing code in this modular format is that you can use ...
    (alt.lang.asm)
  • Re: malloc syntax
    ... > programmers. ... > misunderstanding of the whole point of having a pointer to void type. ... Now in C of course, other operations are defined, such as implicit casts ...
    (comp.lang.c)
  • Re: build faster
    ... Which is faster right now, locating testing and learning the library, writing your own, or just coding from scratch. ... In addition to writing reuseable code you should be writing expandable code that is backward compatible. ... Now I see a lot of work other programmers have done where there is no OO, there often are no functions, this is all embedded calls and includes in html. ... A competent programmer seldom starts from scratch and has libraries of code which can be used on almost any project ...
    (comp.lang.php)
  • Re: About method comments
    ... names and writing test cases - rather than writing prose in comments. ... programmers have the talent to write good extended prose. ... Otherwise how is the author of the external documentation to know /what/ to ... Those two reasons alone make me recommend commenting /every/ method. ...
    (comp.lang.smalltalk)
  • Re: Portability: Harmony between PC and microcontroller
    ... so programmers writing looks-like-C for them need to be ... I was hesitant to rely on rules from the Standard when it ... The problem comes with writing portable code. ...
    (comp.lang.c)