Purpose of sequence points

[Daniel Kraft]

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!

[red floyd]

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.

[Daniel Kraft]

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!

[Victor Bazarov]

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

[James Kanze]

On Jun 15, 8:47 pm, Daniel Kraft <[e-mail] rote:

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: ja*********@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]