[Bug c/20181] New: Increment/decrement

[d_picco at hotmail dot com]

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.

-- 
   Summary: Increment/decrement
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: d_picco at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20181

[Bug c/20181] Increment/decrement

[d_picco at hotmail dot com]

--- Additional Comments From d_picco at hotmail dot com  2005-02-23 20:24 
---
(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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20181

[Bug c/11751] wrong evaluation order of an expression

[d_picco at hotmail dot com]

--- Additional Comments From d_picco at hotmail dot com  2005-02-23 20:38 
---
The point I was making with my example is that the native types (int, long,
char, etc...) have different behaviour than a user-defined class with the
operator++.  If it is compiler dependent which way the expression is evaluated,
why not at least make them both agree?  GCC is also the only compiler out of the
5 that I've tested that exhibits this behaviour... all others unify the
behaviour of native and user-defined operator++. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751

[Bug c/11751] wrong evaluation order of an expression

[d_picco at hotmail dot com]

--- Additional Comments From d_picco at hotmail dot com  2005-02-23 20:46 
---
Here is a better clarification:

Case 1
==
int a = 0;
int b = a++ + a++;
printf("b = %d\n", b);  // output is 0


Case 2
==
class A
{
  int a_;
public:
  A() : a_(0) {}

  int operator++() { return a_++; }
};

A a;
int b = a++ + a++;
printf("b = %d\n", b);  // output is 1

This is a simple case that shows how the behaviour of the operator++ should be
united.

I'm not sure what you mean by the system(...) call... I understand that the code
is undefined (meaning its up to the compiler vendor to implement as they see
fit).  I think the most fitting way is to have the above two cases unified in
behaviour... isn't one of the reasons that operators were added to C++ was to
allow user-defined types to mimic the functionality and usability of the native
C types?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751

[Bug c/11751] wrong evaluation order of an expression

[d_picco at hotmail dot com]

--- Additional Comments From d_picco at hotmail dot com  2005-02-23 23:27 
---
I won't press the issue further because I have other things more pressing ;)

But I think the decision to not change the behaviour here is wrong.  I cannot
create an Integer class that acts as an int due to the operator++.  Just because
it is undefined does not mean that we have to arbitrarily have to choose a
method that adds no value over one that adds good value.  Nearly all other
compiler vendors have adopted this method since it has an element of
common-sense in the face of an undefined process.  I get the feeling that the
only reason it isn't changed is simply because no-one wants to do it.  If there
is another reason, what is it?  

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751