Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

103734

Guest
Original poster
Apr 10, 2007
723
0
Ok I just got into working with xcode and so far this is the only thing I don't understand at all.

Why does this return 7
HTML:
unsigned int x, number;
x=4;
number = 2 + ++x;

While this returns 6
HTML:
unsigned int x, number;
x=4;
number = 2 + x++;

I just don't get why x++ means add 1 after the calculation and why ++x means before :confused:

Im sorry for such a noobish question but im just getting started and this is really confusing me.
 
The first example returns 7...

Before the calculation vs after means exactly what it sounds like.
Code:
x = 2
y = 2 + x
// x == 2, y == 4
Here, x remains the same

Code:
x = 2
y = 2 + x++
// x == 3, y == 4
Here, y is calculated with x as 2, then x is incremented afterwards.

Code:
x = 2
y = 2 + ++x
// x == 2, y == 5
Here, x is incremented, then y is calculated with x as 3.
 
Yea, the ++ only affects the variable on which it is attached, not the rest of the formula. It is handy when you are using "x" as a counter in a while loop and need to increment it while also using that value in a calculation. Saves memory, that is why it is there.

TEG
 
Yea, the ++ only affects the variable on which it is attached, not the rest of the formula. It is handy when you are using "x" as a counter in a while loop and need to increment it while also using that value in a calculation. Saves memory, that is why it is there.

TEG
It doesn't save memory, nor does it save CPU cycles -- its just easier to write than having it on another line...
 
This has nothing to do with XCode. This is just C syntax. There is a prefix increment and a postfix increment.

Both alter their operand, but they evaluate to different things. The prefix operator evaluates to the value of the variable after incrementing. The postfix operator evaluates to the value of the variable before incrementing.

I don't know if using functions will be clearer to you now or not, but I'll give it a try.

Code:
int prefixIncrement(int *x) {
  *x = *x +1;
  return *x;
}

int postfixIncrement(int *x) {
  int temp = *x;
  *x = *x +1;
  return temp;
}

int main(int argc, char *argv[]) {
  int a,b,c;
  a = 5;
  b = prefixIncrement(&a);
  printf("a is: %d, b is: %d\n",a,b);
  a = 5;
  c = postfixIncrement(&a);
  printf("a is: %d, c is: %d\n",a,c);
  return 0;
}

The output is:
a is 6, b is 6
a is 6, c is 5

prefixIncrement(&a) is the same as ++a.
postfixIncrement(&a) is the same as a++.

Every expression has some sort of value in C (though sometimes it is void... which means it doesn't... there are always exceptions). Even things that don't seem like they should:
Code:
int main(int argc, char *argv[]) {
  int a,b,c,d;
  a = 5;
  b = 7;
  c = 0;
  d = 0;
  d = c = b + a;
  printf("a is: %d, b is: %d, c is: %d, d is %d\n",a,b,c,d);
  return 0;
}

Output:
a is: 5, b is: 7, c is: 12, d is: 12

The expression:
Code:
c = b + a
evaluates to the left-hand operand of the = after the assignment has occurred. This leads to the common error:
Code:
if(a = b) {
  ...
} else {
  ...
}

In this case, the condition is evaluating the value of a after b is assigned to it. This means that if b is any value other than 0, the conditional is true, no matter what a is. This is rarely, if ever, the real intention.

I hope this helps to some degree. I am afraid if you are just getting started programming this may have muddled things further, and if so, my apologies (and try to forget it completely).

-Lee

P.S. Try this on for size:
Code:
int a,b,c;
a = 5
b = 7;
c = a+++++b;
=) It amuses me that you can do that and it's valid. To the OP: What are the values for a, b, and c when this finishes?
 
It doesn't save memory, nor does it save CPU cycles -- its just easier to write than having it on another line...

It does help in C++ in the presence of operator overloading, so it can be a good habit to get into if C++ work is anticipated. Generally pointless though, I agree :)
 
It doesn't save memory, nor does it save CPU cycles -- its just easier to write than having it on another line...

It does save on memory, from back when C and C++ were developed, because every byte on both the development machine and platform were at a premium.

TEG
 
Is there really an argument about whether ++ is more efficient than += 1 or x = x +1? Is the argument that you're saving bytes in your source code having fewer characters, and that it could matter? I suppose operator overloading makes the compiler work a bit harder in C++, but there is no affect at runtime.

The standard doesn't say anything about how the machine code gets generated, but using gcc prefix and postfix ++, += 1 and x = x +1 all resulted in the exact same instructions for C and C++.

-Lee
 
...but using gcc prefix and postfix ++, += 1 and x = x +1 all resulted in the exact same instructions for C and C++.

Perhaps the same machine code instructions are generated for simple statements such as:
Code:
++x;

// and

x++;

...but you will obviously get different machine code for these two statements:
Code:
fn(++x);

// and

fn(x++);
 
Perhaps the same machine code instructions are generated for simple statements such as:
Code:
++x;

// and

x++;

...but you will obviously get different machine code for these two statements:
Code:
fn(++x);

// and

fn(x++);

I was just commenting on efficiency. Those better evaluate differently. =)

-Lee
 
It does save on memory, from back when C and C++ were developed, because every byte on both the development machine and platform were at a premium.

TEG
Sorry, but no...
Incrementing a variable first of all does not change the amount of memory you need. Secondly, if you write a[x++]=2, when it gets converted to machine code it sets a[x]=2, then x++.

And if you really really don't believe me, try this:
Code:
        int a[8];
        int x = 0;

        a[++x] = 1;
        a[x++] = 2;

Code:
        int a[8];
        int x = 0;

        x++;
        a[x] = 1;
        a[x] = 2;
        x++;
Compile them, then diff them. The binaries are IDENTICAL!

Edit: note -- its not supposed to do anything meaningful ;)
 
what if I wanted to add two before the calculation I could type +++x?
or does it only work for ++x? I think im going to just write it out right now because its easier for me to read
 
what if I wanted to add two before the calculation I could type +++x?
or does it only work for ++x? I think im going to just write it out right now because its easier for me to read

There is no such operator as +++. You can achieve this with:
x+=2;

There is no unary increment by 2.

-Lee
 
There is no such operator as +++. You can achieve this with:
x+=2;

There is no unary increment by 2.

-Lee


ahh ok i get it now

thanks everyone!

Code:
int a,b,c;
a = 5
b = 7;
c = a+++++b;
Is it b = 11 a = 5 and c = 16?

or is b =7?

Im not quite sure lol
 
ahh ok i get it now

thanks everyone!

Code:
int a,b,c;
a = 5
b = 7;
c = a+++++b;
Is it b = 11 a = 5 and c = 16?

or is b =7?

Im not quite sure lol

It's easier to read if you pull it apart:
Code:
c = a++ + ++b;

So a and b are both going to be incremented by 1. So a is 6, and b is 8. a isn't incremented until after the expression is evaluated, so c is 13 (original value of a, 5, plus the incremented value of b, 8).

-Lee
 
This link may be helpful...

For C++, any operator applied to an object could do ANYTHING. ++myObject could send an encrypted message to the CIA, and myObject++ could start your coffee brewing. I'm not sure which of those operations performs better, but the point is that once you start talking about overloading everything goes out the window because arbitrary code is executed.

-Lee

Edit: The link you posted is certainly relevant, I didn't mean to trivialize the information that it provides. I just wanted to point out that we (or at least I) were discussing the operator's behavior on primitives.
 
One more question so I don't have to make a new thread.

Is Programming in Objective-C still a good book if im working in leopard? I heard there is objective-C 2.0 now and I was wondering if that book will still be ok to buy or if the info in it is obsolete now?
 
One more question so I don't have to make a new thread.

Is Programming in Objective-C still a good book if im working in leopard? I heard there is objective-C 2.0 now and I was wondering if that book will still be ok to buy or if the info in it is obsolete now?

It would be fine. Seeing as it concentrates on the language and not the Xcode IDE so much. It won't hurt to learn with Objective-C 1.0 at all. Objective-C 2.0 does not add a whole lot really.
 
It would be fine. Seeing as it concentrates on the language and not the Xcode IDE so much. It won't hurt to learn with Objective-C 1.0 at all. Objective-C 2.0 does not add a whole lot really.

agreed. garbage collection is a big deal, but knowing how to manage memory properly in the absence of a garbage collection is not a bad thing. Once you know the basics swapping out some property declarations in the place of writing your own accessors/mutators, some fast enumeration for explicit iterator use, etc. won't be hard to learn.

-Lee
 
Edit: The link you posted is certainly relevant, I didn't mean to trivialize the information that it provides. I just wanted to point out that we (or at least I) were discussing the operator's behavior on primitives.

Yes, which is also discussed at the top of my link - from that page:
For intrinsic types like int, it doesn't matter: ++i and i++ are the same speed...
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.