plus if you have come down to the point where you try to optimize such a trivial thing, chances are your doing something horribly wrong somewhere else.
plus if you have come down to the point where you try to optimize such a trivial thing, chances are your doing something horribly wrong somewhere else.
STL Util a small headers-only library with various utility functions. Mainly for fun but feedback is welcome.
Why do you think that? That would depend entirely on the values of x, y and m. Pick whichever makes sense.Sorry, I'm not articulating this very well. Here is some code where += and = will produce the same result in many situations.
andCode:y = x;
Code:y += m;
Suppose you wanted to set y (initalized to 0) equal to x. Which would you do?
OrCode:y = x;
I would choose the first, because then both me and others would understand what this code is meant to do.Code:y += x;
I can't remember a single instance where I wondered: hm, should I do assignment or addition? - Eh, I'll pick whichever is faster.
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
Sorry tinman, but the point still stands. y = x and y += m do completely different things, so comparing which is faster makes little sense. Use the one that does what you want. If you want to add to y, use +=. If you want to ignore y's current value and assign to it, use =.
The only question that makes sense is this:versus:Code:y = 0; // x = ? y = x;Those two code snippets do exactly the same thing (assuming normal addition semantics) only because y is 0 and adding x to 0 is the same as assigning x. However, in that case which version you use would depend on which is clearer given the context, not efficiency concerns.Code:y = 0; // x = ? y += x;
Your question leaves out the y = 0, so it makes little sense. For example, if y is 5 and x is 10 you have this:versus:Code:y = 5; x = 10; y = x; // y is now 10.See... it doesn't matter which is faster, because they produce different results.Code:y = 5; x = 10; y += x; // y is now 15.
It's already been mentioned: no.
But this reminded me of the reverse:
Find the [implementation] library function call(s) on the highlighted line.Code:#define ADDRESS 0x400 struct sType1 { unsigned char c; unsigned int i; } Object1 = {5,0}; struct sType2 { unsigned char a; unsigned char b; unsigned char d[50]; unsigned int e; } Object2; int foo(void) { unsigned int addr1, addr2 = ADDRESS + (sizeof(Object2) * (Object1.c - 1)); addr1 = Object1.c - 1; /* implicit cast of char */ addr1 *= sizeof(Object2); addr1 += ADDRESS; return addr1 == addr2; }
Last edited by Dave_Sinkula; 06-05-2007 at 09:46 PM. Reason: After a long struggle to find the right word.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
Sounds like a lea x86 instruction could compute this.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
If you are hinting at the multiply, then yes. It was on a platform that either did not have a multiply operation, or had only an 8-bit multiply -- I forget. The multiplication was implemented using a function call.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*