precedence

Discussion in 'C++' started by Gernot Frisch, Sep 14, 2004.

  1. "Andy White" <> schrieb im Newsbeitrag
    news:...
    > the statement:
    >
    > foo.b[0] = 7;
    >
    > indicates the first element of the array member of the data
    > structure. My
    > question is, why aren't the brackets evaluated first then the dot
    > operator
    > after since the brackets are higher on the precedence chart? Thanks


    Er... The content of the braces _is_ evaluated first:

    long fkt(void)
    {
    printf("fkt");
    return 0;
    }

    class FOO
    {
    public:
    long& B(){printf("access B "); return b;}
    long b;
    };

    FOO foo[100];
    foo.B()[fkt()] = 7;
    Gernot Frisch, Sep 14, 2004
    #1
    1. Advertising

  2. In article <>, Andy White
    <> writes
    >the statement:
    >
    >foo.b[0] = 7;
    >
    >indicates the first element of the array member of the data structure. My
    >question is, why aren't the brackets evaluated first then the dot operator
    >after since the brackets are higher on the precedence chart? Thanks


    Because you start from the name, in this case 'foo' The subscript
    operator is not appropriate to foo, and b isn't a free variable but one
    that is identified in the context of foo.


    --
    Francis Glassborow ACCU
    Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
    For project ideas and contributions: http://www.spellen.org/youcandoit/projects
    Francis Glassborow, Sep 14, 2004
    #2
    1. Advertising

  3. Gernot Frisch

    Sumit Rajan Guest

    "Andy White" <> wrote in message
    news:...
    > the statement:
    >
    > foo.b[0] = 7;
    >
    > indicates the first element of the array member of the data structure. My
    > question is, why aren't the brackets evaluated first then the dot operator
    > after since the brackets are higher on the precedence chart? Thanks


    A '[]' operator does not have higher precedence than a '.' operator. They
    have the SAME precedence.

    Regards,
    Sumit.
    Sumit Rajan, Sep 14, 2004
    #3
  4. Gernot Frisch

    Chris Dollin Guest

    Andy White wrote:

    > the statement:
    >
    > foo.b[0] = 7;
    >
    > indicates the first element of the array member of the data structure. My
    > question is, why aren't the brackets evaluated first then the dot operator
    > after since the brackets are higher on the precedence chart? Thanks


    (a) because precedence doesn't determine order of evaluation - it determines
    what expressions are operands of what operators.

    (b) the order of evaluation of the operands of [] is not specfied in
    C [dunno about C++, I suspect not].

    --
    Chris "electric hedgehog" Dollin
    C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
    C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
    Chris Dollin, Sep 14, 2004
    #4
  5. Gernot Frisch

    Andy White Guest

    the statement:

    foo.b[0] = 7;

    indicates the first element of the array member of the data structure. My
    question is, why aren't the brackets evaluated first then the dot operator
    after since the brackets are higher on the precedence chart? Thanks
    Andy White, Sep 14, 2004
    #5
  6. Andy White wrote:
    > the statement:
    >
    > foo.b[0] = 7;
    >
    > indicates the first element of the array member of the data structure. My
    > question is, why aren't the brackets evaluated first then the dot operator
    > after since the brackets are higher on the precedence chart? Thanks


    Firstly, C++ language does not have a "precedence chart". It has a
    grammar, which also happens to determine what we usually refer to as
    operator precedence and associativity. And according to C++ grammar, the
    above expression should be interpreted as operator '[]' applied to
    'foo.b'. Any "precedence charts" are noting more than attempts to more
    or less closely represent operator relationship determined by C++
    grammar in linear (more readable) form. You just found an example where
    the chart you are using doesn't work very well.

    Secondly, operator precedence and associativity defines grouping of
    operators with their operands? but it doesn't define in any way the
    order of evaluation of these operators. Hence, you question about
    something being (or not being) "evaluated first" (and/or "evaluated
    after") doesn't make much sense in this context.

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Sep 14, 2004
    #6
  7. In article <>, Andrey Tarasevich
    <> writes
    >Secondly, operator precedence and associativity defines grouping of
    >operators with their operands? but it doesn't define in any way the
    >order of evaluation of these operators. Hence, you question about
    >something being (or not being) "evaluated first" (and/or "evaluated
    >after") doesn't make much sense in this context.


    OK, we have a problem linguistic problem here. Expressions are evaluated
    and neither C nor C++ specify the order of evaluation of
    sub-expressions. However both provide rules about how operators are
    sequenced. The grammar largely specifies the order in which operators
    are to be handled. For example

    x = a*b*c/d;

    allows any order for obtaining values from a, b, c and d but requires
    that a*b be evaluated prior to the evaluation of that result * c which
    must happen prior to the evaluation of that expression/d.

    Where it get complicated is when we have for example:

    y = (a+b) * (c+d);
    Now either a+b or c+d can be evaluated first because there is no
    ordering applied to multiple instances of expressions in parentheses.

    Clear as mud to most people. Basically do not write code where the order
    in which the sub-expressions are evaluated makes any difference to the
    result.


    --
    Francis Glassborow ACCU
    Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
    For project ideas and contributions: http://www.spellen.org/youcandoit/projects
    Francis Glassborow, Sep 14, 2004
    #7
  8. Francis Glassborow wrote:
    >>Secondly, operator precedence and associativity defines grouping of
    >>operators with their operands? but it doesn't define in any way the
    >>order of evaluation of these operators. Hence, you question about
    >>something being (or not being) "evaluated first" (and/or "evaluated
    >>after") doesn't make much sense in this context.

    >
    > OK, we have a problem linguistic problem here. Expressions are evaluated
    > and neither C nor C++ specify the order of evaluation of
    > sub-expressions. However both provide rules about how operators are
    > sequenced. The grammar largely specifies the order in which operators
    > are to be handled. For example
    >
    > x = a*b*c/d;
    >
    > allows any order for obtaining values from a, b, c and d but requires
    > that a*b be evaluated prior to the evaluation of that result * c which
    > must happen prior to the evaluation of that expression/d.


    No, it does not require that.

    It is worth noting that it is difficult to come to a definite answer in
    this case, because we are taking about built-in operators and there's no
    way to detect the order in which built-in operators are invoked by the
    implementation. For this very reason I don't like the notion of "order
    of evaluation" applied to built-in operators.

    Grouping between operand and operators ultimately defines the _result_
    of the expression, but not the order of evaluation of its
    subexpressions. The implementation is free to choose absolutely any
    method of evaluation that leads to the correct result. In the above case
    the compiler is free to start with evaluating, say, 'b/d' if it knows
    how to ensure that the final value in 'x' is correct.

    It is worth noting that in many cases order of evaluation is tied to the
    correctness of the result much more than it would be in abstract
    mathematics (like in situations when intermediate subexpressions can
    produce overflows, precision loss etc). In such cases evaluating the
    expression in "canonical" order (defined by precedence and
    associativity) is the most straightforward way to ensure that the result
    is correct. But, once again, the compiler is not required to do it this way.

    > Where it get complicated is when we have for example:
    >
    > y = (a+b) * (c+d);
    > Now either a+b or c+d can be evaluated first because there is no
    > ordering applied to multiple instances of expressions in parentheses.


    This expression can also be evaluated as the sum of 'a*c', 'a*d', 'b*c'
    and 'b*d', if the compiler chooses to so for some reason and is capable
    of ensuring that the final result is correct.

    > Clear as mud to most people. Basically do not write code where the order
    > in which the sub-expressions are evaluated makes any difference to the
    > result.


    Yes, as long as there are no side effects. Side effect make things much
    more complicated. I've seen people, who'd erroneously apply the above
    rule and come to the conclusion that the following expression is OK,
    because it "doesn't depend on the order of evaluation":

    const int a[] = { 1, 2, 3 };
    const int* p = a;

    int sum = *p++ + *p++ + *p++; // <- this one

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Sep 14, 2004
    #8
  9. Andrey Tarasevich wrote:
    > [...]
    > It is worth noting that in many cases order of evaluation is tied to the
    > correctness of the result much more than it would be in abstract
    > mathematics (like in situations when intermediate subexpressions can
    > produce overflows, precision loss etc). In such cases evaluating the
    > expression in "canonical" order (defined by precedence and
    > associativity) is the most straightforward way to ensure that the result
    > is correct. But, once again, the compiler is not required to do it this way.


    Pardon the interruption...

    I know that "notes" are not normative, but 1.9/15, while being a note,
    does talk about the compiler being prohibited from rewriting expressions
    in such way that it might produce an exception in certain cases.

    Is this what you mean by "not required"? And if it's not really required,
    why does the Standard contain the words "the implementation cannot rewrite
    this expression"?

    > [...]


    Victor
    Victor Bazarov, Sep 14, 2004
    #9
  10. Victor Bazarov wrote:
    >> [...]
    >> It is worth noting that in many cases order of evaluation is tied to the
    >> correctness of the result much more than it would be in abstract
    >> mathematics (like in situations when intermediate subexpressions can
    >> produce overflows, precision loss etc). In such cases evaluating the
    >> expression in "canonical" order (defined by precedence and
    >> associativity) is the most straightforward way to ensure that the result
    >> is correct. But, once again, the compiler is not required to do it this way.

    >
    > Pardon the interruption...
    >
    > I know that "notes" are not normative, but 1.9/15, while being a note,
    > does talk about the compiler being prohibited from rewriting expressions
    > in such way that it might produce an exception in certain cases.
    >
    > Is this what you mean by "not required"? And if it's not really required,
    > why does the Standard contain the words "the implementation cannot rewrite
    > this expression"?
    >
    >> [...]


    When used the term "result" in my previous message, I used it in its
    broader meaning than the one assumed in C++ standard. My mistake. What I
    really meant might be best referred to as, say, "outcome" of the
    evaluation process, which includes obtaining result as well as, for
    example, generating (or not generating) the exception mentioned in the note.

    I don't argue that one elegant way to describe the evaluation of
    expressions in C++ is to use the "as if" rule, i.e. to say that
    expressions are evaluated "as if" the exact order of evaluation is
    defined by operator precedence and associativity. The only problem I see
    with it is that often in practical situations the meaning of "as if" in
    the above sentence gets misunderstood or lost completely.

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Sep 14, 2004
    #10
    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. David Frauzel

    Operator precedence

    David Frauzel, May 13, 2004, in forum: Perl
    Replies:
    2
    Views:
    536
    Luc Van Hove
    May 17, 2004
  2. Replies:
    1
    Views:
    8,794
    Siva M
    Sep 15, 2005
  3. kbd

    Operator Precedence

    kbd, Jul 22, 2004, in forum: Java
    Replies:
    10
    Views:
    741
    Roedy Green
    Jul 27, 2004
  4. Replies:
    3
    Views:
    405
    Roedy Green
    Sep 13, 2005
  5. Andrew Koenig
    Replies:
    10
    Views:
    538
    Ron Natalie
    Jul 14, 2003
Loading...

Share This Page