 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Vladimir Guest
|
Posted: Wed Dec 29, 2004 9:18 pm Post subject: Re: Ambiguous Expression |
|
|
Victor Bazarov wrote:
| Quote: | So, the change to some stored value (the side effect of 'rand')
does not happen more than once between sequence points.
|
Here's smallest code reproducing the problem, where func() represents
typical rand() implementation in very simplified form:
inline int func()
{
static int state = 0;
return ++state;
}
int main()
{
std::cout << func() << func() << std::endl;
return 0;
}
Debug build produces "21" which is ok, but Release build
outputs "22" which ruins expected sequence-generating behavior.
I tested it with vc++ 6.0 and I'm interested what other compilers
would offer (note: global optimizations were heavily used).
--
Vladimir
|
|
| Back to top |
|
 |
Victor Bazarov Guest
|
Posted: Wed Dec 29, 2004 9:33 pm Post subject: Re: Ambiguous Expression |
|
|
Vladimir wrote:
| Quote: | Victor Bazarov wrote:
So, the change to some stored value (the side effect of 'rand')
does not happen more than once between sequence points.
Here's smallest code reproducing the problem, where func() represents
typical rand() implementation in very simplified form:
inline int func()
{
static int state = 0;
return ++state;
}
|
To make it compile on all compilers, add:
#include <iostream> // for 'std::cout'
#include <ostream> // for 'std::endl'
| Quote: |
int main()
{
std::cout << func() << func() << std::endl;
return 0;
}
Debug build produces "21" which is ok, but Release build
outputs "22" which ruins expected sequence-generating behavior.
I tested it with vc++ 6.0 and I'm interested what other compilers
would offer (note: global optimizations were heavily used).
|
VC++ v7.1 produces "21" in debug mode and "22" in release mode (no
surprises there).
VC++ v8.0 Beta produces "21" in both debug and release modes.
Which is not to say that any of them are "correct", only that they
differ, as they may.
Victor
|
|
| Back to top |
|
 |
Pete Becker Guest
|
Posted: Wed Dec 29, 2004 9:45 pm Post subject: Re: Ambiguous Expression |
|
|
Victor Bazarov wrote:
| Quote: |
=> VC++ v7.1 produces "21" in debug mode and "22" in release mode (no
surprises there).
VC++ v8.0 Beta produces "21" in both debug and release modes.
Which is not to say that any of them are "correct", only that they
differ, as they may.
|
That is, "21" or "12" is okay, but "22" is definitely wrong, because it
violates the rules about sequence points.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
|
|
| Back to top |
|
 |
Victor Bazarov Guest
|
Posted: Wed Dec 29, 2004 9:49 pm Post subject: Re: Ambiguous Expression |
|
|
Pete Becker wrote:
| Quote: | Victor Bazarov wrote:
=> VC++ v7.1 produces "21" in debug mode and "22" in release mode (no
surprises there).
VC++ v8.0 Beta produces "21" in both debug and release modes.
Which is not to say that any of them are "correct", only that they
differ, as they may.
That is, "21" or "12" is okay, but "22" is definitely wrong, because it
violates the rules about sequence points.
|
Ah... Good point (no pun intended). So, optimization should not prevent
any side effects from taking place, yes? My guess is that circumventing
side effects is only allowed in particular cases and they are described in
the Standard explicitly.
V
|
|
| Back to top |
|
 |
Pete Becker Guest
|
Posted: Wed Dec 29, 2004 10:03 pm Post subject: Re: Ambiguous Expression |
|
|
Victor Bazarov wrote:
| Quote: | Ah... Good point (no pun intended). So, optimization should not prevent
any side effects from taking place, yes? My guess is that circumventing
side effects is only allowed in particular cases and they are described in
the Standard explicitly.
|
They're not described explicitly, but the "as if" rule (1.5/1) is the
thing to look to. The standard specifies the observable behavior of
well-formed programs. The behavior of this program depends on
unspecified behavior, but that doesn't make it ill-formed, so the
compiler must produce a program with the observable behavior specified
by the standard. It can't blow away the sequence point after the first
call (in the generated code, not the fist in the source code) to func.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
|
|
| Back to top |
|
 |
Vladimir Guest
|
Posted: Wed Dec 29, 2004 10:20 pm Post subject: Re: Ambiguous Expression |
|
|
So,
vc++ v6.0 debug "21", release "22"
vc++ v7.1 debug "21", release "22"
vc++ v8.0 Beta "21" in both debug and release modes.
Something tells me v8.0 *Final* will catch up with previous versions
ok, it's OT - I'm hiding right now.
--
Vladimir
|
|
| Back to top |
|
 |
Vladimir Guest
|
Posted: Wed Dec 29, 2004 10:33 pm Post subject: Re: Ambiguous Expression |
|
|
Pete Becker wrote:
| Quote: | by the standard. It can't blow away the sequence point after the
first
call (in the generated code, not the fist in the source code) to
func. |
IMHO there is no sequence point between arg1 and arg2 evaulations in a
call(arg1, arg2);
is it?
--
Vladimir
|
|
| Back to top |
|
 |
Victor Bazarov Guest
|
Posted: Wed Dec 29, 2004 10:42 pm Post subject: Re: Ambiguous Expression |
|
|
Vladimir wrote:
| Quote: | Pete Becker wrote:
by the standard. It can't blow away the sequence point after the
first
call (in the generated code, not the fist in the source code) to
func.
IMHO there is no sequence point between arg1 and arg2 evaulations in a
call(arg1, arg2);
is it?
|
It depends on what 'arg1' and 'arg2' are. If they are function calls,
there is _always_ a sequence point between them (before the second call,
which is not necessarily to evaluate 'arg2'). That's what Pete said.
And it has nothing to do with opinions. It's specified by the Standard.
V
|
|
| Back to top |
|
 |
Attila Feher Guest
|
Posted: Thu Dec 30, 2004 3:08 pm Post subject: Re: Ambiguous Expression |
|
|
Ron Natalie wrote:
| Quote: | Ioannis Vranos wrote:
int x;
Vect2D v((x=rand(), rand()), x);
That's worse. The second argument to the
v initializer may be evaluated before the first.
|
That said, it could be fun to make a contest (like the obfuscated C one) for
C++. Where the code looks like doing one thing, but in fact it does another
(or nothing specified). I know that the above is "only C", but in C++ we
could put some spice on it by having converting constructors and implicit
conversion operators, broken copy constructors, reference members etc. ;-)
--
Attila aka WW
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|