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.
 

sord

macrumors 6502
Jun 16, 2004
352
0
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.
 

TEG

macrumors 604
Jan 21, 2002
6,625
173
Langley, Washington
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
 

sord

macrumors 6502
Jun 16, 2004
352
0
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...
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
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?
 

Catfish_Man

macrumors 68030
Sep 13, 2001
2,579
2
Portland, OR
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 :)
 

TEG

macrumors 604
Jan 21, 2002
6,625
173
Langley, Washington
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
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
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
 

kalimba

macrumors regular
Jun 10, 2008
102
0
...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++);
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
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
 

sord

macrumors 6502
Jun 16, 2004
352
0
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 ;)
 

103734

Guest
Original poster
Apr 10, 2007
723
0
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
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
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
 

103734

Guest
Original poster
Apr 10, 2007
723
0
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
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
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
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
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.
 

103734

Guest
Original poster
Apr 10, 2007
723
0
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?
 

Cromulent

macrumors 604
Oct 2, 2006
6,816
1,101
The Land of Hope and Glory
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.
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
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
 

laprej

macrumors regular
Oct 14, 2005
108
2
Troy, NY
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.