Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Ambiguous Expression

Reply
Thread Tools

Ambiguous Expression

 
 
Vladimir
Guest
Posts: n/a
 
      12-28-2004
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

 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      12-28-2004
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
 
Reply With Quote
 
 
 
 
Vladimir
Guest
Posts: n/a
 
      12-28-2004
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

 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      12-29-2004
"Vladimir" <(E-Mail Removed)> 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


 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      12-29-2004
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
 
Reply With Quote
 
Ron Natalie
Guest
Posts: n/a
 
      12-29-2004
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.
 
Reply With Quote
 
Vladimir
Guest
Posts: n/a
 
      12-29-2004

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

 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      12-29-2004
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)
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      12-29-2004
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
 
Reply With Quote
 
Vladimir
Guest
Posts: n/a
 
      12-29-2004

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression" Adem C++ 42 11-04-2008 12:39 PM
C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression" Adem C Programming 45 11-04-2008 12:39 PM
Ambiguous type in infix expression jens VHDL 4 10-15-2008 11:59 AM
Ambiguous reference to type jahaya@gmail.com VHDL 2 09-12-2005 09:55 AM
Ambiguous type? Tuukka Toivonen VHDL 3 05-03-2004 02:36 PM



Advertisments