Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Purpose of sequence points

Reply
Thread Tools

Purpose of sequence points

 
 
red floyd
Guest
Posts: n/a
 
      06-15-2007
Daniel Kraft wrote:
> Hi all!
>
> I do not have a standard-document right next to me to cite from, but as
> far as I know, doing something like:
>
> a()=b()=c()=d();
> or
> foo(d()+c()+b()+a());
>
> has a fixed evaluation order (right-to-left in the first case and
> left-to-right in the second one), although there are no sequence points
> inside the =- or +-expression.
>
> (Please correct me if I'm wrong here)


You're wrong. The compiler is free to calculate the operands a(), b(),
c(), and d() in any order. The order of the *arithmetic calculation* is
defined. The compiler can say "calcluate b(), then a(), then c(), then
d(), and store them in temps b, a, c, d, respecitvely. Then evaluate
((d + c) + b) +a. So the associativity and precedence of the operations
is defined, but the order of evaluation of the operands isn't.
 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      06-15-2007
Daniel Kraft wrote:
> red floyd wrote:
>> Daniel Kraft wrote:
>>> Hi all!
>>>
>>> I do not have a standard-document right next to me to cite from, but
>>> as far as I know, doing something like:
>>>
>>> a()=b()=c()=d();
>>> or
>>> foo(d()+c()+b()+a());
>>>
>>> has a fixed evaluation order (right-to-left in the first case and
>>> left-to-right in the second one), although there are no sequence
>>> points inside the =- or +-expression.
>>>
>>> (Please correct me if I'm wrong here)

>>
>> You're wrong. The compiler is free to calculate the operands a(),
>> b(), c(), and d() in any order. The order of the *arithmetic
>> calculation* is defined. The compiler can say "calcluate b(), then
>> a(), then c(), then d(), and store them in temps b, a, c, d,
>> respecitvely. Then evaluate ((d + c) + b) +a. So the associativity
>> and precedence of the operations is defined, but the order of
>> evaluation of the operands isn't.

>
> I see -- but what is this restriction really for?


It's not a restriction. It would be a restriction if the order were
prescribed. Since it's unspecified, it's a non-restriction (what's
the antonym of 'restriction'?)

> To help the
> compiler optimize the code? At least this is the only reason I can
> think of.


Not to help optimise but rather not to impede possible optimisations.

> (Of course, this isn't really a restriction which hurts much; but it's
> surely not there just for the sake of restricting the language)


It's there for exactly the opposite purpose - of NOT restricting.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


 
Reply With Quote
 
 
 
 
Daniel Kraft
Guest
Posts: n/a
 
      06-15-2007
Hi all!

I do not have a standard-document right next to me to cite from, but as
far as I know, doing something like:

a()=b()=c()=d();
or
foo(d()+c()+b()+a());

has a fixed evaluation order (right-to-left in the first case and
left-to-right in the second one), although there are no sequence points
inside the =- or +-expression.

(Please correct me if I'm wrong here)

So, other than the order of evaluation of arguments to a function call:
foo(a(), b(), c(), d());

a, b, c and should be called in reverse order (d, c, b, a) for my first
two examples, right? For the third one, it is unspecified, AFAIK.

But when I do something like:
a=b=a=b or (++a)+(a++)

this is invalid due to multiple modification inbetween sequence points.
So here my question: What is the purpose of this rule, as in these
cases the order is well defined despite the fact there are no sequence
points? Is this to help the compiler optimize or could real ambiguities
occur?

Yours,
Daniel


--
Got two Dear-Daniel-Instant Messages
by MSN, associate ICQ with stress --
so please use good, old E-MAIL!
 
Reply With Quote
 
Daniel Kraft
Guest
Posts: n/a
 
      06-15-2007
red floyd wrote:
> Daniel Kraft wrote:
>> Hi all!
>>
>> I do not have a standard-document right next to me to cite from, but
>> as far as I know, doing something like:
>>
>> a()=b()=c()=d();
>> or
>> foo(d()+c()+b()+a());
>>
>> has a fixed evaluation order (right-to-left in the first case and
>> left-to-right in the second one), although there are no sequence
>> points inside the =- or +-expression.
>>
>> (Please correct me if I'm wrong here)

>
> You're wrong. The compiler is free to calculate the operands a(), b(),
> c(), and d() in any order. The order of the *arithmetic calculation* is
> defined. The compiler can say "calcluate b(), then a(), then c(), then
> d(), and store them in temps b, a, c, d, respecitvely. Then evaluate
> ((d + c) + b) +a. So the associativity and precedence of the operations
> is defined, but the order of evaluation of the operands isn't.


I see -- but what is this restriction really for? To help the compiler
optimize the code? At least this is the only reason I can think of.

(Of course, this isn't really a restriction which hurts much; but it's
surely not there just for the sake of restricting the language)

Yours,
Daniel

--
Got two Dear-Daniel-Instant Messages
by MSN, associate ICQ with stress --
so please use good, old E-MAIL!
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      06-16-2007
On Jun 15, 8:47 pm, Daniel Kraft <(E-Mail Removed)> wrote:
> red floyd wrote:
> > Daniel Kraft wrote:
> >> I do not have a standard-document right next to me to cite from, but
> >> as far as I know, doing something like:


> >> a()=b()=c()=d();
> >> or
> >> foo(d()+c()+b()+a());


> >> has a fixed evaluation order (right-to-left in the first case and
> >> left-to-right in the second one), although there are no sequence
> >> points inside the =- or +-expression.


> >> (Please correct me if I'm wrong here)


> > You're wrong. The compiler is free to calculate the operands a(), b(),
> > c(), and d() in any order. The order of the *arithmetic calculation* is
> > defined. The compiler can say "calcluate b(), then a(), then c(), then
> > d(), and store them in temps b, a, c, d, respecitvely. Then evaluate
> > ((d + c) + b) +a. So the associativity and precedence of the operations
> > is defined, but the order of evaluation of the operands isn't.


> I see -- but what is this restriction really for? To help the compiler
> optimize the code? At least this is the only reason I can think of.


It makes it slightly easier for the compiler writer, by making
it a lot harder for you to test.

> (Of course, this isn't really a restriction which hurts much; but it's
> surely not there just for the sake of restricting the language)


Historically, with the primitive compiler technologies available
in the 1970's, it probably did make a difference. Today, I
doubt it.

--
James Kanze (Gabi Software) email: http://www.velocityreviews.com/forums/(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
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
Question about sequence points spibou@gmail.com C Programming 3 08-12-2006 10:01 PM
Knowing your sequence points akarl C Programming 7 08-12-2005 02:21 AM
Does C++ have sequence points ? Timothy Madden C++ 4 09-21-2004 08:21 AM
Sequence points Dave Theese C++ 2 09-03-2003 08:16 AM
Sequence points j C Programming 4 07-24-2003 11:14 AM



Advertisments