GCC Bugzilla has been upgraded from version 4.4.9 to 5.0rc3. If you see any problem, please report it to bug 64968.
Bug 20181 - Increment/decrement
Summary: Increment/decrement
Status: RESOLVED DUPLICATE of bug 11751
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.4.3
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-23 20:22 UTC by Dion Picco
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dion Picco 2005-02-23 20:22:54 UTC
Consider these situations:

int a = 0;
int b = a++ + a++;
int c = (a++) + (a++);
int d = a++ + (a++);
int e = (a++) + a++;

b == c == d == e == 0.  I understand based on a previous bug about sequence
points in C++ but I think a common-sense approach takes precident here.  If 'a'
were a user-defined class with the operator++ (postfix), how could the user
mimic such behaviour, namely b == c == d == e == 0?  In fact they couldn't.  The
proper solution is then to have b == c == d == e == 1.
Comment 1 Dion Picco 2005-02-23 20:24:27 UTC
(In reply to comment #0)
> Consider these situations:
> 
> int a = 0;
> int b = a++ + a++;
> int c = (a++) + (a++);
> int d = a++ + (a++);
> int e = (a++) + a++;
> 
> b == c == d == e == 0.  I understand based on a previous bug about sequence
> points in C++ but I think a common-sense approach takes precident here.  If 'a'
> were a user-defined class with the operator++ (postfix), how could the user
> mimic such behaviour, namely b == c == d == e == 0?  In fact they couldn't.  The
> proper solution is then to have b == c == d == e == 1.

I should have clarified this more:

Consider these situations:

Case 1
======
int a = 0;
int b = a++ + a++

Case 2
======
int a = 0;
int c = (a++) + a++;

Case 3
======

... etc

Otherwise b != c != d != e if the situations were read sequentially
Comment 2 Andrew Pinski 2005-02-23 20:26:16 UTC

*** This bug has been marked as a duplicate of 11751 ***

*** This bug has been marked as a duplicate of 11751 ***