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]

Fao, Sean wrote:

cout << p << " " << p++ << " " << ++p << endl;
Is there a bug in the code, or in the compilers?

In the FAQ.

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

/David

[Sumit Rajan]

"David Rasmussen" <da*************@gmx.net> wrote in message
news:bu**********@news.net.uni-c.dk...

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

[Jonathan Turkanis]

"David Rasmussen" <da*************@gmx.net> wrote in message
news:bu**********@news.net.uni-c.dk...

Fao, Sean wrote:

cout << p << " " << p++ << " " << ++p << endl;
Is there a bug in the code, or in the compilers?

In the FAQ.

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/Article...ncePoints.html

Jonathan

[Pete Becker]

Sumit Rajan wrote:

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

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

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[osmium]

David Rasmussen writes:

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

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

[David Rasmussen]

osmium wrote:

David Rasmussen writes:

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

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]

Pete Becker wrote:

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]

David Rasmussen wrote:

Fao, Sean wrote:

cout << p << " " << p++ << " " << ++p << endl;
Is there a bug in the code, or in the compilers?

In the FAQ.

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 Goodsell]

David Rasmussen wrote:

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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Ron Natalie]

"David Rasmussen" <da*************@gmx.net> wrote in message news:bu**********@news.net.uni-c.dk...

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]

"Pete Becker" <pe********@acm.org> wrote in message news:40***************@acm.org...

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]

"David Rasmussen" <da*************@gmx.net> wrote in message news:bu**********@news.net.uni-c.dk...
=> cout << p << " " << p++ << " " << ++p << endl;

}

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]

"Ron Natalie" <ro*@sensor.com> wrote in message news:40***********************@news.newshosting.co m...

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]

David Rasmussen wrote:

osmium wrote:

David Rasmussen writes:

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

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?

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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Ron Natalie]

"Pete Becker" <pe********@acm.org> wrote in message news:40***************@acm.org...

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]

"Ron Natalie" <ro*@sensor.com> wrote in message
news:40***********************@news.newshosting.co m...

"Pete Becker" <pe********@acm.org> wrote in message news:40***************@acm.org...

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.

I made the same mistake above.

Jonathan

[Kevin Saff]

"Jonathan Turkanis" <te******@kangaroologic.com> wrote in message
news:bu************@ID-216073.news.uni-berlin.de...

"David Rasmussen" <da*************@gmx.net> wrote in message
news:bu**********@news.net.uni-c.dk...

Fao, Sean wrote:

> cout << p << " " << p++ << " " << ++p << endl;
>Is there a bug in the code, or in the compilers?
In the FAQ.

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

more

specific?

I couldn't either.

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

--
KCS

[Pete Becker]

Ron Natalie wrote:

"Pete Becker" <pe********@acm.org> wrote in message news:40***************@acm.org...

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++.

Where is the sequence point between the two increments?

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Pete Becker]

Ron Natalie wrote:

"Ron Natalie" <ro*@sensor.com> wrote in message news:40***********************@news.newshosting.co m...

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.

Ah, that's the point. Okay, unspecified here. Undefined for builtin
types. Bad business either way.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Ron Natalie]

"Pete Becker" <pe********@acm.org> wrote in message news:40***************@acm.org...

Ron Natalie wrote:

"Pete Becker" <pe********@acm.org> wrote in message news:40***************@acm.org...

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++.

Where is the sequence point between the two increments?

They are done inside a SUBROUTINE. Operator++ is overloaded (these
are ENUMs). There is an sequence point after the value p is passed to the
function and when the value is returned.

[Pete Becker]

Ron Natalie wrote:

They are done inside a SUBROUTINE.

A SUBROUTINE? This isn't FORTRAN. In C++ we have functions. <g>

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Ron Natalie]

"Pete Becker" <pe********@acm.org> wrote in message news:40***************@acm.org...

Ron Natalie wrote:

They are done inside a SUBROUTINE.

A SUBROUTINE? This isn't FORTRAN. In C++ we have functions. <g>

Hey, at least I didn't invoke it with GOSUB.

[David Rasmussen]

Kevin Goodsell wrote:

Where is there a sequence point problem?

There is none, as others have pointed out. I meant the undefined
evaluation order problem.

/David