^ I agree... but please don't say 'natural'... after another thread I started, I plan on completely deleting the word 'natural' from my vocabulary...
Printable View
^ I agree... but please don't say 'natural'... after another thread I started, I plan on completely deleting the word 'natural' from my vocabulary...
How about:
a += 1;
I'm tending to use that more and more often. It just looks better and clearer.
:rolleyes: oookkk....Quote:
Originally posted by Speedy5
How about:
a += 1;
I'm tending to use that more and more often. It just looks better and clearer.
Unless I am using the return value for something (which is fairly rare) forcing the issue, I prefer to use ++a.
Yes, but the only difference is a single subtraction operation done by the processor. If you need to optimize things like that, do what Sebastiani said and use asm.Quote:
Originally posted by Prelude
>Indeed.
I think you missed the point. A well known micro-optimization technique is to invert the loop, starting from the end and decrementing. This is on the assumption that some machines have a special instruction for decrementing and comparing with zero and a reversed loop is a good hint to the compiler to use those instructions.
are you insane? how doesQuote:
Originally posted by Speedy5
How about:
a += 1;
I'm tending to use that more and more often. It just looks better and clearer.
look better thanCode:a += 1;
:rolleyes: i just don't get it...Code:a++;
//or
++a;
I use that only when it's a number other an 1.Quote:
Originally posted by Speedy5
How about:
a += 1;
I'm tending to use that more and more often. It just looks better and clearer.
For just an incremment of one I usually use a++ out of habit, but sometimes just to be "a little crazy" about things I will use ++a hehe.
C++, there is nothing better than this.
I wonder if there will ever be a language based on C++ called C+=2
Hey, I made that joke a few weeks ago :P
I do tend to use ++a (or --a) unless I need the old value. Although any good optimizing compiler should make no distinction, ++a is:
* As readable as a++
* Never worse in performance than a++ and sometimes better
I agree, increment/decrement is not the place to look at optimizing, but this is not your typical optimization, because there is no benefit from a++ if you don't need the old value. Optimization is all about making decisions based on tradeoffs. For example, do you want a fast program or a small one? Do you want to take advantage of processor-specific features that might slow your program down on other systems? Do you want to keep your classes very uncoupled, making code changes easier and bugs rarer, or do you need the added speed that tighter coupling can provide?
In this case, if there is only one side of the story -- if ++a is always as good and possibly better (at least in cases where ++ has the typical meaning), then I think ++a is the way to go.
a++ is much faster than ++a because its easier for the 'a' to push the ++ forward in the program rather than pull it. dont you agree that pushing is easier than pulling?
pulling is much easier when your in practise :)
According to the discussion of whether ++a is faster than a++ I have made a few tests. i compiled the test program below (without optimizations) and got the following results:
EDIT:
Old code, see next page for updated test
As you can see, not much differs from them. They have the same instructions run, only in a different order. My conclusion from this is they are both running at the same speed. If someone else have anything to add, please do.
EDIT: Another observation. In a = a++ there is this line:
This could be optimized away, thus making a=a++ faster.Code:mov eax, DWORD PTR _a$[ebp]
mov DWORD PTR _a$[ebp], eax
>This could be optimized away, thus making a=a++ faster.
Why would you want to optimize undefined behavior?
> Why would you want to optimize undefined behavior?
Well would you want it slow... There's no fun in that. :D