Re: simple increment operator question.
From: Jeff Schwab (jeffplus_at_comcast.net)
Date: 12/23/03
- Next message: Jeff Schwab: "Re: std streams and enum?"
- Previous message: Jeff Schwab: "Re: Passing args dilema"
- In reply to: The Real OS/2 Guy: "Re: simple increment operator question."
- Next in thread: Chris Newton: "Re: simple increment operator question."
- Reply: Chris Newton: "Re: simple increment operator question."
- Reply: The Real OS/2 Guy: "Re: simple increment operator question."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 22 Dec 2003 22:53:13 -0500
The Real OS/2 Guy wrote:
> On Mon, 22 Dec 2003 06:19:22 UTC, Jeff Schwab <jeffplus@comcast.net>
> wrote:
>
>
>>Usually, it's a good idea to avoid the post-increment operator, in favor
>>of something like this:
>
>
> That's a wrong advise. Learn C right. If you don't know how an
> operator works you can't use C anyway.
If you're working with C++ generic types, you *can't* always know how a
given operator works. Post-increment is never necessary, and is often
inefficient.
>> m_pVertices[ i_ArrayIndex ] = a;
>> ++i_ArrayIndex;
>
>
> Following your advise it must be:
>
> i_ArrayIndex = iArrayIndex + 1 * 1;
What??? How on Earth did you figure that?
>>Or, initialize i to -1 instead of 0, and do this:
>>
>> m_pVertices[ ++iArrayIndex ] = a;
>
>
> That is wrong! Foolowing the guides you would declare
> size_t iArrayIndex;
No, you wouldn't. Array indexes are int's by definition. Also, the OP
was kind enough to use Hungarian notation: the "i" prefix on the
variable name means it's an int. An unsigned value would begin with n.
> as it should be an index ending up at lest with the size of the array.
> For that the type size_t exists. Misleading by negative index is
> confusing. An index in C starts always with 0, not a negative number.
> Using postincrement when ever possible results in
> - better readability
Occasionally.
> - often in more optimal code.
Never.
> Using preindex can even be useful - but not when you have to use
> tricks as you do to get it working.
What tricks did I use?
> You have to learn how the operators in works. You gets confising
> yourself and other by not knowing it exactly.
>
>
>>The reason is that some overloaded post-increment operators have to make
>>copies of the objects being incremented.
>
>
> In contrast some overloaded post-increment gives better optimised
> code. Don't stink against the compiler! Use post or preincrement as
> you have to make thinks clean - not to destroy the abilities of your
> compiler to make optimasions right. A primitive compiler without good
> optimisation ability will produce better code for
> x[i++] = y[z++] as when you writes
> x[i] = y[z], i++, z++;
> A compiler with an better optimiser will even equal code for both. But
> you yob is NOT to optimise on microlevel as you tries - but to write
> good code, good readable for humans.
If find it sadly ironic that someone so concerned with the readability
of code cares so little for readability of a newsgroup post. I'm having
a hard time reading your text.
>>If you're not sure of the meaning of a line involving only built-in
>>types, you might find it useful to look at the assembly code. If you're
>>on a Unix-like system, try the -S flag to your compiler, and look for a
>>file with a .s extension.
>
>
> Wrong advise. I've never seen assember code for more than 15 years -
> because there was absolutely no need for. Hand optimising for one
> comiler makes the next one (even the next subversion of the same
> generating more bad code than using only C.
>
> There is no real cause for an C programmer to learn the about 3.498
> assember OP codes with all its modifications a modern processor
> understunds - except you have to write an code generator that has to
> generate mshine code based on the C sources.
I don't know what you mean at all...
> Learn C right to write C programs, learn assember of a particular
> mashine right to write assember on that, learn another programming
> language right when you have to write code in that language. But ever
> you have to learn the language right and completely to write correct
> and error free code.
>
> When you means that the code the compiler generates is too slow don't
> botch on single statements - user another algorithm to tune the work
> up.
>
Single statements that include overloaded operators can be highly
significant. In particular, pre-increment and post-increment are often
called repeatedly in loops that need to be very tight.
I think you misunderstood my original post, partly by ignoring C++.
Nobody's saying that every statement in a program must be optimized for
a particular compiler or platform. However, there are some habits that
are good to develop early, and understanding what machine-level
instructions C or C++ code generates can be useful and interesting.
Anyway, I didn't mean to step on your toes, but I stand by my advice.
- Next message: Jeff Schwab: "Re: std streams and enum?"
- Previous message: Jeff Schwab: "Re: Passing args dilema"
- In reply to: The Real OS/2 Guy: "Re: simple increment operator question."
- Next in thread: Chris Newton: "Re: simple increment operator question."
- Reply: Chris Newton: "Re: simple increment operator question."
- Reply: The Real OS/2 Guy: "Re: simple increment operator question."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
