Find The Bug

[David Rasmussen]

I have this code:

#include <iostream>

using namespace std;

#define DeclareEnumTricks(T) \
inline T& operator++(T& e) \
{ \
e = T(e+1); \
return e; \
} \
\
inline T operator++(T& e, int) \
{ \
T old = e; \
e = T(e+1); \
return old;\
} \
\
inline T& operator--(T& e) \
{ \
e = T(e-1); \
return e; \
} \
\
inline T operator--(T& e, int) \
{ \
T old = e; \
e = T(e-1); \
return old; \
} \
\
inline T end(T) \
{ \
return T##_end; \
} \
\
inline T begin(T) \
{ \
return T##_begin; \
}

enum Piece {none,pawn,knight,bishop,rook,queen,king,
Piece_begin = pawn, Piece_end = king + 1};
DeclareEnumTricks(Piece)

int main()
{
Piece p = none;
cout << p << " " << p++ << " " << ++p << endl;
}

The output from g++ and several other compilers is _not_

0 0 2

as expected. In g++ it is

2 1 1

Is there a bug in the code, or in the compilers?

/David

 

[Fao, Sean]

cout << p << " " << p++ << " " << ++p << endl;

Is there a bug in the code, or in the compilers?

In the FAQ.

 

[David Rasmussen]

In the FAQ.

Thanks. I've looked, but I can't find anything relevant. Could be more
specific?

/David

 

[Sumit Rajan]

I have this code:

#include <iostream>

using namespace std;

#define DeclareEnumTricks(T) \
inline T& operator++(T& e) \
{ \
e = T(e+1); \
return e; \
} \
\
inline T operator++(T& e, int) \
{ \
T old = e; \
e = T(e+1); \
return old;\
} \
\
inline T& operator--(T& e) \
{ \
e = T(e-1); \
return e; \
} \
\
inline T operator--(T& e, int) \
{ \
T old = e; \
e = T(e-1); \
return old; \
} \
\
inline T end(T) \
{ \
return T##_end; \
} \
\
inline T begin(T) \
{ \
return T##_begin; \
}

enum Piece {none,pawn,knight,bishop,rook,queen,king,
Piece_begin = pawn, Piece_end = king + 1};
DeclareEnumTricks(Piece)

int main()
{
Piece p = none;
cout << p << " " << p++ << " " << ++p << endl;
}

The output from g++ and several other compilers is _not_

0 0 2

as expected. In g++ it is

2 1 1

Is there a bug in the code, or in the compilers?

/David

Comeau C++ came up with the expected output: 0 0 2

 

[Pete Becker]

Comeau C++ came up with the expected output: 0 0 2

Doesn't matter what's expected. What matters is what's required. The
behavior of the program is undefined. Anything goes.

 

[Jonathan Turkanis]

Thanks. I've looked, but I can't find anything relevant. Could be more
specific?

I couldn't either. Try this:

http://www.langer.camelot.de/Articles/VSJ/SequencePoints/SequencePoints.html

Jonathan

 

[David Rasmussen]

David Rasmussen writes:



Did you allow for the fact that shift left has a lower precedence than
postfix ++ and prefix ++?

Even if, the first p should print out as 0. Shouldn't it?

/David

 

[David Rasmussen]

Doesn't matter what's expected. What matters is what's required. The
behavior of the program is undefined. Anything goes.

I would sure like to know why...

/David

 

[Fao, Sean]

Thanks. I've looked, but I can't find anything relevant. Could be more
specific?

I thought I had seen it in the C++ FAQ at one time but I might just be
dreaming. Oh well, it's in the C FAQ for the same reason...

http://www.eskimo.com/~scs/C-faq/s3.html

 

[David Rasmussen]

Thanks!

I don't know what I was thinking. I know about the sequencing point type
problem. My mind was focused on the macros. I was sure I had some bug.

/David

 

[Kevin Saff]

I couldn't either.

Neither could I. There must be a bug in the FAQ.

 

[Kevin Goodsell]

Thanks!

I don't know what I was thinking. I know about the sequencing point type
problem. My mind was focused on the macros. I was sure I had some bug.

Where is there a sequence point problem?

-Kevin

 

[Ron Natalie]

cout << p << " " << p++ << " " << ++p << endl;
}

The output from g++ and several other compilers is _not_

0 0 2

as expected. In g++ it is

2 1 1

Is there a bug in the code, or in the compilers?

In the code. You have undefined behavior. You modify p multiple
times between sequence point for certain allowable orderings.

 

[Ron Natalie]

Doesn't matter what's expected. What matters is what's required. The
behavior of the program is undefined. Anything goes.

Not undefined, it's just that his operators are invoked in an unspecified order.
Remember there are overloads for the operator++.

 

[Ron Natalie]

}

Argument evaluation order is not fixed in C++. The order of evaluating:
the three subexpressions "p", "p++" and "++p" is unspecified. Might happen
left to right, my happen right to left, might happen in any order. All you know
is that they happen before their respective << operators (but no guarantee
with respect to each other).

 

[Ron Natalie]

In the code. You have undefined behavior. You modify p multiple
times between sequence point for certain allowable orderings.

BZZT. Caught myself here. Not undefined behavior as there are inherent
sequence points in the function calls. operator ++ is overloaded here.

 

[Pete Becker]

Even if, the first p should print out as 0. Shouldn't it?

Nope. The behavior of the code is undefined, so there's nothing it
"should" do. I can't tell from your messages whether you've seen what
the problem is. Here's a simpler version:

cout << i++ << i++;

The code modifies the value of i twice without an intervening sequence
point.

 

[Ron Natalie]

cout << i++ << i++;

The code modifies the value of i twice without an intervening sequence
point.

No it does not. The ++ operators are overloads. There are sequence points
before and after the modification (the ones inherent in calling and returning from
functions).

His only sin is to expect that function arguments are to be evaluated in some particular
order.

 

[Jonathan Turkanis]

No it does not. The ++ operators are overloads. There are sequence points
before and after the modification (the ones inherent in calling and returning from
functions).

His only sin is to expect that function arguments are to be evaluated in some particular
order.

I made the same mistake above.

Jonathan

 

[Pete Becker]

Not undefined, it's just that his operators are invoked in an unspecified order.
Remember there are overloads for the operator++.

Where is the sequence point between the two increments?