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.
Printable View
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.
Why do you think that? That would depend entirely on the values of x, y and m. Pick whichever makes sense.Quote:
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.
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;
}
Sounds like a lea x86 instruction could compute this.
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.