Purpose of sequence points

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

  1. red floyd

    red floyd Guest

    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
    #1
    1. Advertising

  2. 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
    Victor Bazarov, Jun 15, 2007
    #2
    1. Advertising

  3. red floyd

    Daniel Kraft Guest

    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
    #3
  4. red floyd

    Daniel Kraft Guest

    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
    #4
  5. red floyd

    James Kanze Guest

    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
    #5
    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. Dave Theese

    Sequence points

    Dave Theese, Sep 3, 2003, in forum: C++
    Replies:
    2
    Views:
    335
    Karl Heinz Buchegger
    Sep 3, 2003
  2. Timothy Madden

    Does C++ have sequence points ?

    Timothy Madden, Sep 20, 2004, in forum: C++
    Replies:
    4
    Views:
    405
    Peter van Merkerk
    Sep 21, 2004
  3. j

    Sequence points

    j, Jul 23, 2003, in forum: C Programming
    Replies:
    4
    Views:
    372
    Tak-Shing Chan
    Jul 24, 2003
  4. akarl

    Knowing your sequence points

    akarl, Aug 11, 2005, in forum: C Programming
    Replies:
    7
    Views:
    387
    Jack Klein
    Aug 12, 2005
  5. Question about sequence points

    , Aug 4, 2006, in forum: C Programming
    Replies:
    3
    Views:
    279
    Clark S. Cox III
    Aug 12, 2006
Loading...

Share This Page