Re: simple increment operator question.
From: The Real OS/2 Guy (os2guy_at_pc-rosenau.de)
Date: 12/22/03
- Next message: Jack.: "Fairly simple c++ question."
- Previous message: Chris Newton: "Re: Scripting Language Tutorial"
- In reply to: Jeff Schwab: "Re: simple increment operator question."
- Next in thread: Jeff Schwab: "Re: simple increment operator question."
- Reply: Jeff Schwab: "Re: simple increment operator question."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 22 Dec 2003 17:31:28 +0000 (UTC)
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.
> m_pVertices[ i_ArrayIndex ] = a;
> ++i_ArrayIndex;
Following your advise it must be:
i_ArrayIndex = iArrayIndex + 1 * 1;
> 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;
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
- often in more optimal code.
Using preindex can even be useful - but not when you have to use
tricks as you do to get it working.
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 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.
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.
-- Tschau/Bye Herbert Visit http://www.ecomstation.de the home of german eComStation
- Next message: Jack.: "Fairly simple c++ question."
- Previous message: Chris Newton: "Re: Scripting Language Tutorial"
- In reply to: Jeff Schwab: "Re: simple increment operator question."
- Next in thread: Jeff Schwab: "Re: simple increment operator question."
- Reply: Jeff Schwab: "Re: simple increment operator question."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
