gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Beginners > --variable or variable-- (which does what?)

#18191 - yaustar - Mon Mar 22, 2004 4:03 pm

A question that has been bugging me for some time but cant get a straight answer, what us the difference between decrimenting this way:
Code:
--a
and this way?
Code:
a--


Thanks
_________________
[Blog] [Portfolio]

#18194 - Lupin - Mon Mar 22, 2004 4:12 pm

i think it's for post and pre in-/de-crementing of array indexes...
_________________
Team Pokeme
My blog and PM ASM tutorials

#18195 - poslundc - Mon Mar 22, 2004 4:27 pm

--a decrements the value of "a" before it is evaluated in any expressions.
a-- first evaluates "a" for any expressions, then decrements it.

So the following conditional statement:

Code:
if (--a == 5)


... first decrements a, then compares it to 5, whereas

Code:
if (a-- == 5)


... reads the current value of a before decrementing, then compares that to five.

If the increment/decrement operators are used as simple statements without comparisons, eg.

Code:
a++;
--b;


... then there is no difference between the pre- and post-versions.

Dan.

Last edited by poslundc on Mon Mar 22, 2004 4:28 pm; edited 1 time in total

#18196 - DekuTree64 - Mon Mar 22, 2004 4:28 pm

Yes, in a single statement it makes no difference, but in a comparison, like
Code:
i = 0;
while(i++ < 8){}

When that ends, i will be 9, because when i is 7, it says 'is i less than 8? yes. increment i to 8. loop', then when i is 8, it says 'is i less than 8, no. increment i to 9. break'.
Then if you do like
Code:
while(++i < 8){}

i will be 8 at the end, because when i is 7, it says 'increment i to 8. is i less than 8? no. break'
It's just the order that it does it in. Sometimes you want one, sometimes the other.

EDIT: Curse you, Dan. One minute too late :P
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#18197 - yaustar - Mon Mar 22, 2004 4:30 pm

thanks :)
_________________
[Blog] [Portfolio]

#18203 - jma - Mon Mar 22, 2004 4:53 pm

Sorry, just have to say, any language which allows this sucks...

Code:
int a,b = 2, c = 5;
a = b+++c;


Any guesses for 'a', 'b' and 'c' (without using your compiler)? :P

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org

#18205 - poslundc - Mon Mar 22, 2004 4:59 pm

Without using the compiler? My guess is:

a = 7
b = 3
c = 5

EDIT: figured I'd post my reasoning: pre- and post-increment operators are the same operational level, and evaluate from left to right. So b++ is read in first by the compiler, and +c is left over. Someone let me know if I'm wrong.

Dan.

#18210 - yaustar - Mon Mar 22, 2004 6:00 pm

I agree with poslundc, a = 7, b = 3, c = 5.
_________________
[Blog] [Portfolio]

#18219 - Miked0801 - Mon Mar 22, 2004 6:52 pm

I think that I'd fire the person who wrote that for making me think so long about it and for introducing bugs into code. :P

The compiler should throw an "Ambiguous<sp> contruct, consider using parenthesis." type warning on that one. In GBA left to right held, but on GBC, the @^&# thing read right to left which really enforced the use () if you aren't 100% sure metality. :)

#18225 - yaustar - Mon Mar 22, 2004 7:55 pm

oh, now I see where the confusion can lie in the code :P. That would be nasty..
Code:
a = (b++)+c
//or
a = b+(++c)
I agree, that sucks >:( Thanks for pointing that out
_________________
[Blog] [Portfolio]

#18244 - tepples - Tue Mar 23, 2004 1:01 am

Miked0801 wrote:
The compiler should throw an "Ambiguous<sp> contruct, consider using parenthesis." type warning on that one. In GBA left to right held, but on GBC, the @^&# thing read right to left which really enforced the use () if you aren't 100% sure metality. :)

The GBA C compiler is GCC, which aims to follows the ANSI C standard as closely as possible. The GBC has an 8080-like processor; because such 8-bit architectures don't lend themselves as easily to C as 16-bit or 32-bit architectures, the GCC team doesn't even think about supporting them. Other compiler publishers (such as the maintainers of CC65, a C compiler targeting the 6502 architecture) may put other features before strict conformance.

That said, I have a habit of putting spaces around addition, subtraction, and most other operators lower on the priority chart. I'm 90 percent sure any C compiler's tokenizer could tell the difference between 'c++ + d' and 'c + ++d'. (That extra 10 percent pushes me to use parentheses.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#18246 - Miked0801 - Tue Mar 23, 2004 1:21 am

Yep, but I'm tlaking about the Z80 assembler I used. For Constant math run in preprocessor, the thing didn't follow the C standards I was used to. For that matter, I never wrote a single line of C for the GBC, all Z80 as the thing was just too slow for much else.

#18249 - Paul Shirley - Tue Mar 23, 2004 3:17 am

removed

Last edited by Paul Shirley on Sun Mar 28, 2004 8:57 pm; edited 1 time in total

#18252 - Miked0801 - Tue Mar 23, 2004 5:07 am

lmao! That's awesome. Something out of an obfuscated coding contest for sure. :)

#18267 - poslundc - Tue Mar 23, 2004 6:56 am

Paul Shirley wrote:
The real horror of C is things like this
Code:
int i = 1;
i = ++i + ++i;
which has an undefined result!


Hm, why is this undefined?

Top priority: pre-increment operator
Processing left to right: ++i == 2, ++i == 3

Next priority: addition operator
2 + 3 == 5

Bottom priority: assignment operator
i <- 5

GCC would seem to agree with me...

Dan.

#18270 - sgeos - Tue Mar 23, 2004 7:22 am

Miked0801 wrote:
I think that I'd fire the person who wrote that for making me think so long about it and for introducing bugs into code. :P


If that code was anything other that a joke or an example of bad style, I think we consider shooting the coder as a general software quality assurance measure. 80% of the errors are in 20% of the code. On a five person team, I'm sure that close to 100% of the bugs are the fault of that person. /rant

-Brendan

#18272 - Miked0801 - Tue Mar 23, 2004 7:52 am

lol ;)

#18277 - Paul Shirley - Tue Mar 23, 2004 1:26 pm

removed

Last edited by Paul Shirley on Sun Mar 28, 2004 8:57 pm; edited 1 time in total

#18281 - poslundc - Tue Mar 23, 2004 4:24 pm

Paul Shirley wrote:
...because C doesn't specify what order the ++ takes effect on i


It does, though: when in the prefix position the increment is applied before evaluation of the variable, and compound expressions are evaluated one-at-a-time, atomically.

Therefore i must be incremented each time before it is used in the expression.

I do not see how any properly-implemented C compiler could generate the first result.

Dan.

#18383 - NoMis - Thu Mar 25, 2004 9:45 am

don't write so much ugly code in this forum. :)

NoMis

#18893 - bats - Wed Apr 07, 2004 8:18 pm

VC 6 returns 6 for the same example.

Code:

main()
{
  int i;
  i = ++i + ++i;
  printf("%d\n",i);
}


seems undefined to me.

edit:
hmm... my GCC gives 6 also.
seems as though it gets translated to
Code:

i = 1
++i
++i
i = i + i

#18896 - poslundc - Wed Apr 07, 2004 9:01 pm

I find that very disturbing. I want it to be 5.

Dan.

#18899 - col - Wed Apr 07, 2004 10:52 pm

poslundc wrote:
Without using the compiler? My guess is:

a = 7
b = 3
c = 5

EDIT: figured I'd post my reasoning: pre- and post-increment operators are the same operational level, and evaluate from left to right. So b++ is read in first by the compiler, and +c is left over. Someone let me know if I'm wrong.

Dan.


I think you have the correct answer, but the wrong reasoning :)
b++ is read in first because the lexer is 'greedy' - it will always grab the largest valid symbol that it can.

cheers

Col

#18900 - poslundc - Wed Apr 07, 2004 11:02 pm

But b++ and ++c are the same size, and same operational level. Doesn't it default to left-to-right processing at that point?

Dan.

#18901 - col - Wed Apr 07, 2004 11:04 pm

poslundc wrote:
Paul Shirley wrote:
The real horror of C is things like this
Code:
int i = 1;
i = ++i + ++i;
which has an undefined result!


Hm, why is this undefined?

...

Dan.


because the increment is only guaranteed to have been applied to i at the next 'sequence point' which in this case is the semi-colon. So it would be legal for the compiler to translate this as eg:
Code:

int i = 1;
int i2 = i + 1;
int i3 = i + 1;
i = i + 1;
i = i + 1;
i = i2 + i3;


cheers

Col

#18903 - col - Wed Apr 07, 2004 11:15 pm

poslundc wrote:
But b++ and ++c are the same size, and same operational level. Doesn't it default to left-to-right processing at that point?

Dan.


AFAIK, it always grabs its symbols left to right, so even if ++c had higher priority than b++, the compiler would still see it as:
b ++ + c.

cheers

Col

#18905 - jma - Wed Apr 07, 2004 11:31 pm

col wrote:

AFAIK, it always grabs its symbols left to right, so even if ++c had higher priority than b++, the compiler would still see it as:
b ++ + c.

It has nothing to do with the precedence of ++ (pre) vs. ++ (post). There is no distinction between the two in the compiler; the operator is ++ . The precedence is between ++ and + . ++ Has a higher precedence than +, so it happens first.

This can be confirmed in multiple ways (ANS spec, trying it out, etc). However, a simple way is to try:

Code:
c = a ++ b;


Of course, this is a syntax error. But what error? It is a missing ; before identifier 'b' error. Or some other similar error (like operator missing). Why doesn't the compiler see + (+b); which works...? (that was rhetorical). Because ++ has the higher order of precedence.

God, what did I start? :P

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org

#18906 - col - Wed Apr 07, 2004 11:47 pm

jma wrote:
col wrote:

AFAIK, it always grabs its symbols left to right, so even if ++c had higher priority than b++, the compiler would still see it as:
b ++ + c.

It has nothing to do with the precedence of ++ (pre) vs. ++ (post). There is no distinction between the two in the compiler; the operator is ++ . The precedence is between ++ and + . ++ Has a higher precedence than +, so it happens first.

This can be confirmed in multiple ways (ANS spec, trying it out, etc). However, a simple way is to try:

Code:
c = a ++ b;


Of course, this is a syntax error. But what error? It is a missing ; before identifier 'b' error. Or some other similar error (like operator missing). Why doesn't the compiler see + (+b); which works...? (that was rhetorical). Because ++ has the higher order of precedence.

God, what did I start? :P

Jeff


I guess my post wasn't very clear.
The issue i was trying to sort out was how the compiler decides that
b'+++c' means 'b ++ + c' and not 'b + ++ c'
Which has nothing to do with precedence afair.

c++ (and i assume c ?) uses a greedy lexer, so when you give it 'b+++c' as input, it will be read as b ++ + c.
By the time the compiler gets to checking precedence, it has already decided on b++ and +c. Precedence is just used to decide what order to process the operators in - not to decide what the operators are :)

so thats my understanding fwiw (i don't have a copy of the standard, so someone else will need to verify)

cheers

Col

#18907 - col - Thu Apr 08, 2004 12:07 am

jma wrote:
...
This can be confirmed in multiple ways (ANS spec, trying it out, etc). However, a simple way is to try:

Code:
c = a ++ b;


Of course, this is a syntax error. But what error? It is a missing ; before identifier 'b' error. Or some other similar error (like operator missing). Why doesn't the compiler see + (+b); which works...? (that was rhetorical). Because ++ has the higher order of precedence..
Jeff


Its nothing to do with the precedence of ++ and +, the lexer always takes the largest meaningful token it can - in this case ++ this happens before any syntax checking or precedence sorting takes place.

cheers

Col

#18912 - jma - Thu Apr 08, 2004 4:34 am

Yes, I misread the post. The lexer is greedy.

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org

#18915 - poslundc - Thu Apr 08, 2004 6:18 am

I give up on this, especially seeing as I can't even seem to google up the ANSI C spec. Instead I just intend to continue writing clean code, as I always have, so I never have to deal with it. :)

Dan++.