Ambiguous Expression

Discussion in 'C++' started by Vladimir, Dec 28, 2004.

  1. Vladimir

    Vladimir Guest

    Colleagues,

    Suppose I have (in simplified form, of course)

    struct Vect2D {
    double x, y;
    Vect2D(double x_, double y_) : x(x_), y(y_) {}
    };

    which I have to construct with random numbers:

    Vect2D v(rand(), rand());

    But this is "Ambiguous Expression" - i.e. "...language does not
    guarantee the order in which arguments to a function call are
    evaluated."

    I was beaten by such type of code indeed - release and debug builds
    behave differently :(

    Above code is so typical, do I have to force explicit order of argument
    evaluation? It would not be so compact and nice.


    --
    Vladimir
     
    Vladimir, Dec 28, 2004
    #1
    1. Advertising

  2. Vladimir wrote:
    > Colleagues,
    >
    > Suppose I have (in simplified form, of course)
    >
    > struct Vect2D {
    > double x, y;
    > Vect2D(double x_, double y_) : x(x_), y(y_) {}
    > };
    >
    > which I have to construct with random numbers:
    >
    > Vect2D v(rand(), rand());
    >
    > But this is "Ambiguous Expression" - i.e. "...language does not
    > guarantee the order in which arguments to a function call are
    > evaluated."
    >
    > I was beaten by such type of code indeed - release and debug builds
    > behave differently :(
    >
    > Above code is so typical, do I have to force explicit order of argument
    > evaluation? It would not be so compact and nice.


    Of course you do. You always have to account for side effects of function
    calls. However, let me note here that one shouldn't really care about the
    order when _random_ values are concerned, should one?

    V
     
    Victor Bazarov, Dec 28, 2004
    #2
    1. Advertising

  3. Vladimir

    Vladimir Guest

    Victor Bazarov wrote:
    > However, let me note here that one shouldn't really care about the
    > order when _random_ values are concerned, should one?


    I thought so too :)
    But the actual problem isn't the order itself. Modern compilers with
    global opimizations and inlining will reach a situation like

    call(++i, ++i);

    which can result in both arguments being the same!
    That's not really random to me :)


    > > Vect2D v(rand(), rand());

    >
    > Of course you do. You always have to account for side effects of

    function
    > calls.


    But C++ is quite powerful in allowing to use stuff on the fly which
    really helps in large programs. What can be most compact, preferably
    one-line solution to this problem then?


    --
    Vladimir
     
    Vladimir, Dec 28, 2004
    #3
  4. "Vladimir" <> wrote...
    > Victor Bazarov wrote:
    >> However, let me note here that one shouldn't really care about the
    >> order when _random_ values are concerned, should one?

    >
    > I thought so too :)
    > But the actual problem isn't the order itself. Modern compilers with
    > global opimizations and inlining will reach a situation like
    >
    > call(++i, ++i);
    >
    > which can result in both arguments being the same!
    > That's not really random to me :)


    The expression above has undefined behaviour because the object 'i' has
    its _stored_value_ changed more than once between sequence points.

    >> > Vect2D v(rand(), rand());

    >>
    >> Of course you do. You always have to account for side effects of

    > function
    >> calls.

    >
    > But C++ is quite powerful in allowing to use stuff on the fly which
    > really helps in large programs. What can be most compact, preferably
    > one-line solution to this problem then?


    There isn't any. Use separately declared/defined/initialised objects:

    int r1 = rand(), r2 = rand();
    Vect2D v(r1, r2);

    Victor
     
    Victor Bazarov, Dec 29, 2004
    #4
  5. Victor Bazarov wrote:

    > There isn't any. Use separately declared/defined/initialised objects:
    >
    > int r1 = rand(), r2 = rand();
    > Vect2D v(r1, r2);



    What about this?


    int x;

    Vect2D v((x=rand(), rand()), x);


    :)




    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Dec 29, 2004
    #5
  6. Vladimir

    Ron Natalie Guest

    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.
     
    Ron Natalie, Dec 29, 2004
    #6
  7. Vladimir

    Vladimir Guest

    Victor Bazarov wrote:
    > > call(++i, ++i);
    > >
    > > which can result in both arguments being the same!
    > > That's not really random to me :)

    >
    > The expression above has undefined behaviour because the object 'i'

    has
    > its _stored_value_ changed more than once between sequence points.


    Similar situation is with rand() - after inlining, internal value
    (used to hold random state) is changed more than once - that's why
    the problem occurs.


    > There isn't any. Use separately declared/defined/initialised

    objects:
    >
    > int r1 = rand(), r2 = rand();
    > Vect2D v(r1, r2);


    I wish we could always remember to use this when needed.
    What about encapsulating such functions with internal state
    into some special classes which would prevent problems
    (possibly by preventing inlining, etc.)?
    This would make coding much more reliable - which is
    essential in large serious projects.

    P.S. These little things are really important, people.
    They usually make the difference between 99% and 100%
    bug-free software, so I think we shouldn't ignore them.


    --
    Vladimir
     
    Vladimir, Dec 29, 2004
    #7
  8. Vladimir

    Pete Becker Guest

    Vladimir wrote:
    > Victor Bazarov wrote:
    >
    >>>call(++i, ++i);
    >>>
    >>>which can result in both arguments being the same!
    >>>That's not really random to me :)

    >>
    >>The expression above has undefined behaviour because the object 'i'

    >
    > has
    >
    >>its _stored_value_ changed more than once between sequence points.

    >
    >
    > Similar situation is with rand() - after inlining, internal value
    > (used to hold random state) is changed more than once - that's why
    > the problem occurs.
    >


    No, because there's a sequence point before each call to rand.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Dec 29, 2004
    #8
  9. Vladimir wrote:
    > Victor Bazarov wrote:
    >
    >>>call(++i, ++i);
    >>>
    >>>which can result in both arguments being the same!
    >>>That's not really random to me :)

    >>
    >>The expression above has undefined behaviour because the object 'i'

    >
    > has
    >
    >>its _stored_value_ changed more than once between sequence points.

    >
    >
    > Similar situation is with rand() - after inlining, internal value
    > (used to hold random state) is changed more than once - that's why
    > the problem occurs.


    Similar, but no undefined behaviour, only unspecified order of calls.
    Every function call is surrounded by sequence points, so even with
    inlining there would be at least four of them between the program
    decided to call the first 'rand' and calling the 'call' function. So,
    the change to some stored value (the side effect of 'rand') does not
    happen more than once between sequence points.

    >>There isn't any. Use separately declared/defined/initialised

    >
    > objects:
    >
    >> int r1 = rand(), r2 = rand();
    >> Vect2D v(r1, r2);

    >
    >
    > I wish we could always remember to use this when needed.


    And I wish I were young, slim, and healthy.

    > What about encapsulating such functions with internal state
    > into some special classes which would prevent problems
    > (possibly by preventing inlining, etc.)?


    You can try limiting the members of your programming team to using
    some kind of class for that, or a macro, or whatever would resolve
    this issue, but the language does not provide a mechanism (yet) to
    catch all instances of unspecified behaviour. Of course we can always
    hope for better tools at our disposal...

    > This would make coding much more reliable - which is
    > essential in large serious projects.


    I believe you could use some kind of "PC-lint"-like code checker that
    might catch that.

    > P.S. These little things are really important, people.
    > They usually make the difference between 99% and 100%
    > bug-free software, so I think we shouldn't ignore them.


    Of course we shouldn't. And _we_ won't. It's the programmers who don't
    read comp.lang.c++ we should be worrying about :)

    V
     
    Victor Bazarov, Dec 29, 2004
    #9
  10. Vladimir

    Vladimir Guest

    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;
    }

    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
     
    Vladimir, Dec 29, 2004
    #10
  11. Vladimir wrote:
    > 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'

    >
    > 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
     
    Victor Bazarov, Dec 29, 2004
    #11
  12. Vladimir

    Pete Becker Guest

    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.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Dec 29, 2004
    #12
  13. Pete Becker wrote:
    > 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
     
    Victor Bazarov, Dec 29, 2004
    #13
  14. Vladimir

    Pete Becker Guest

    Victor Bazarov wrote:
    > 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)
     
    Pete Becker, Dec 29, 2004
    #14
  15. Vladimir

    Vladimir Guest

    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
     
    Vladimir, Dec 29, 2004
    #15
  16. Vladimir

    Vladimir Guest

    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?


    --
    Vladimir
     
    Vladimir, Dec 29, 2004
    #16
  17. Vladimir wrote:
    > 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
     
    Victor Bazarov, Dec 29, 2004
    #17
  18. Vladimir

    Attila Feher Guest

    Ron Natalie wrote:
    > 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
     
    Attila Feher, Dec 30, 2004
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tuukka Toivonen

    Ambiguous type?

    Tuukka Toivonen, Apr 30, 2004, in forum: VHDL
    Replies:
    3
    Views:
    735
    Stefan Frank
    May 3, 2004
  2. Replies:
    2
    Views:
    1,026
  3. Denon
    Replies:
    2
    Views:
    4,398
    Yuke Liew
    Jan 2, 2004
  4. Nancy.
    Replies:
    3
    Views:
    8,192
    i. Wiin
    Sep 28, 2004
  5. jens
    Replies:
    4
    Views:
    3,974
    Mike Treseler
    Oct 15, 2008
Loading...

Share This Page