# Purpose of sequence points

Discussion in 'C++' started by red floyd, Jun 15, 2007.

1. ### red floydGuest

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.

red floyd, Jun 15, 2007

2. ### Victor BazarovGuest

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

Victor Bazarov, Jun 15, 2007

3. ### Daniel KraftGuest

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!

Daniel Kraft, Jun 15, 2007
4. ### Daniel KraftGuest

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!

Daniel Kraft, Jun 15, 2007
5. ### James KanzeGuest

On Jun 15, 8:47 pm, Daniel Kraft <> 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:
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

James Kanze, Jun 16, 2007