Question about the *= (and similar) operator

Discussion in 'C Programming' started by spibou@gmail.com, Jun 13, 2006.

  1. Guest

    In the statement "a *= expression" is expression assumed to be
    parenthesized ? For example if I write "a *= b+c" is this the same
    as "a = a * (b+c)" or "a = a * b+c" ?
    , Jun 13, 2006
    #1
    1. Advertising

  2. writes:

    >In the statement "a *= expression" is expression assumed to be
    >parenthesized ? For example if I write "a *= b+c" is this the same
    >as "a = a * (b+c)" or "a = a * b+c" ?


    Write a small C program and try it.
    The learning will provide benefits.

    --
    Chris.
    Chris McDonald, Jun 13, 2006
    #2
    1. Advertising

  3. Guest

    Chris McDonald wrote:

    > writes:
    >
    > >In the statement "a *= expression" is expression assumed to be
    > >parenthesized ? For example if I write "a *= b+c" is this the same
    > >as "a = a * (b+c)" or "a = a * b+c" ?

    >
    > Write a small C program and try it.
    > The learning will provide benefits.
    >


    It wouldn't provide any more benefits than what I would get from
    a reply here. Plus experiments are a dangerous way of learning
    about C unless one knows beforehand that the behaviour being
    investigated
    is determined by the standard. If that's not the case then one will not
    know if what he observes is standard or implementation defined or
    undefined which just happened to work in a specific way under a
    specific
    compiler on a specific platform. For all I know , whether "expression"
    is
    parenthesized or not in "a *= expression" , is implementation defined
    and
    if one wants to achieve portability one should include parentheses in
    the
    code whenever the standard operator precedence does not give the
    desired
    result.

    Spiros Bousbouras
    , Jun 14, 2006
    #3
  4. wrote:
    > In the statement "a *= expression" is expression assumed to be
    > parenthesized ? For example if I write "a *= b+c" is this the same
    > as "a = a * (b+c)" or "a = a * b+c" ?
    >


    ISO C99 draft (N1124) ยง6.5.16.2:
    A compound assignment of the form E1 op = E2 differs from the simple
    assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
    evaluated only once.


    --
    one's freedom stops where others' begin

    Giannis Papadopoulos
    Computer and Communications Engineering dept. (CCED)
    University of Thessaly
    http://dop.freegr.net/
    Giannis Papadopoulos, Jun 14, 2006
    #4
  5. In article <>,
    <> wrote:

    >In the statement "a *= expression" is expression assumed to be
    >parenthesized ? For example if I write "a *= b+c" is this the same
    >as "a = a * (b+c)" or "a = a * b+c" ?


    The latter would only be plausible if *= was some kind of macro. If
    you could define infix macros and did

    #define-infix x*=y x=x*y

    then a*=b+c might expand to a=a*b+c.

    But C operators are not like macros. The only question is the
    relative precedence of *= and +. It will either be

    (a *= b) + c, which is equivalent to (a = a*b) + c,
    or
    a *= (b + c), which is equivalent to a = a * (b+c).

    In fact, it's a = a * (b + c), because the assignment operators all
    have lower precedence than the arithmetic operators.

    -- Richard
    Richard Tobin, Jun 14, 2006
    #5
  6. In article <e6nho5$ntu$>,
    Giannis Papadopoulos <> wrote:

    >> In the statement "a *= expression" is expression assumed to be
    >> parenthesized ? For example if I write "a *= b+c" is this the same
    >> as "a = a * (b+c)" or "a = a * b+c" ?


    >A compound assignment of the form E1 op = E2 differs from the simple
    >assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
    >evaluated only once.


    That's not very enlightening, since it doesn't answer the question
    of whether E2 is b or b+c. In particular, the answer is different
    for a *= b,c.

    -- Richard
    Richard Tobin, Jun 14, 2006
    #6
  7. On 13 Jun 2006 15:42:52 -0700
    wrote:

    > In the statement "a *= expression" is expression assumed to be
    > parenthesized ? For example if I write "a *= b+c" is this the same
    > as "a = a * (b+c)" or "a = a * b+c" ?
    >

    If you find this confusing why not simple use parenthesis or not use
    the *= (and like) operator at all?
    Rafael Almeida, Jun 14, 2006
    #7
  8. Richard Tobin wrote:
    > In article <e6nho5$ntu$>,
    > Giannis Papadopoulos <> wrote:
    >
    >>> In the statement "a *= expression" is expression assumed to be
    >>> parenthesized ? For example if I write "a *= b+c" is this the same
    >>> as "a = a * (b+c)" or "a = a * b+c" ?

    >
    >> A compound assignment of the form E1 op = E2 differs from the simple
    >> assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
    >> evaluated only once.

    >
    > That's not very enlightening, since it doesn't answer the question
    > of whether E2 is b or b+c. In particular, the answer is different
    > for a *= b,c.
    >
    > -- Richard


    It says (E2) so why should it be further clarified?

    --
    one's freedom stops where others' begin

    Giannis Papadopoulos
    Computer and Communications Engineering dept. (CCED)
    University of Thessaly
    http://dop.freegr.net/
    Giannis Papadopoulos, Jun 14, 2006
    #8
  9. writes:


    >Chris McDonald wrote:


    >> writes:
    >>
    >> >In the statement "a *= expression" is expression assumed to be
    >> >parenthesized ? For example if I write "a *= b+c" is this the same
    >> >as "a = a * (b+c)" or "a = a * b+c" ?

    >>
    >> Write a small C program and try it.
    >> The learning will provide benefits.
    >>


    >It wouldn't provide any more benefits than what I would get from
    >a reply here. Plus experiments are a dangerous way of learning
    >about C unless one knows beforehand that the behaviour being
    >investigated
    >is determined by the standard. If that's not the case then one will not
    >know if what he observes is standard or implementation defined or
    >undefined which just happened to work in a specific way under a
    >specific
    >compiler on a specific platform. For all I know , whether "expression"
    >is
    >parenthesized or not in "a *= expression" , is implementation defined
    >and
    >if one wants to achieve portability one should include parentheses in
    >the
    >code whenever the standard operator precedence does not give the
    >desired
    >result.



    Sorry, politely, this is bordering on the absurd.
    You do not trust anything you observe from experiments,
    you do not trust anything you get from a reply here,
    you do not trust anything you investigate to be conforming.

    OK, it's your choice to be so suspicious and pedantic, but it's unclear
    what you, or the OP, should ever trust.

    Will you trust your own interpretation of the standard?
    Will you trust anyone's interpretation of the standard?
    And if you do trust your own or anyone else's interpretation of the standard,
    how did you gain that trust?

    If every commodity compiler such as MS-Studio or gcc chose to implement
    the above assignment in an implementation defined fashion, then how is
    anyone to rise to the level of even a basic user?

    Given the nature of the OP's original question, it's clear to anyone
    that a basic experiment, for varying values of a, b, and c, will reveal
    far more insight than all the anal reflection in the world.

    --
    Chris.
    Chris McDonald, Jun 14, 2006
    #9
  10. Guest

    Richard Tobin wrote:

    > In article <e6nho5$ntu$>,
    > Giannis Papadopoulos <> wrote:
    >
    > >> In the statement "a *= expression" is expression assumed to be
    > >> parenthesized ? For example if I write "a *= b+c" is this the same
    > >> as "a = a * (b+c)" or "a = a * b+c" ?

    >
    > >A compound assignment of the form E1 op = E2 differs from the simple
    > >assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
    > >evaluated only once.

    >
    > That's not very enlightening, since it doesn't answer the question
    > of whether E2 is b or b+c. In particular, the answer is different
    > for a *= b,c.


    I don't see any way to parse the expression "a *= b+c" so that E2 turns
    out to be just b.
    , Jun 14, 2006
    #10
  11. writes:
    > In the statement "a *= expression" is expression assumed to be
    > parenthesized ? For example if I write "a *= b+c" is this the same
    > as "a = a * (b+c)" or "a = a * b+c" ?


    All assignment operators, including "*=" and ordinary "=", have the
    same precedence.

    Just as "a = b + c" means "a = (b + c)", "a *= b + c" means "a *= (b + c)".

    Your C textbook should have an operator precedence table or equivalent.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jun 14, 2006
    #11
  12. In article <e6nj7r$p5t$>,
    Giannis Papadopoulos <> wrote:

    >>> A compound assignment of the form E1 op = E2 differs from the simple
    >>> assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
    >>> evaluated only once.


    >> That's not very enlightening, since it doesn't answer the question
    >> of whether E2 is b or b+c. In particular, the answer is different
    >> for a *= b,c.


    >It says (E2) so why should it be further clarified?


    Your reasoning would lead to the (wrong) conclusion that a *= b,c is
    equivalent to a = a * (b,c).

    Yes, you put parentheses around E2, but what *is* E2? Is it b
    or b op c?

    The standard answers the question by means of the sequence of
    productions in section 6.5. a *= b + c is parsed as a *= (b + c)
    because the the right operand of an assignment operator can be an
    additive expression, which b + c is; whereas the left operand of an
    additive expression must be an additive expression, which a *= b
    isn't.

    -- Richard
    Richard Tobin, Jun 14, 2006
    #12
  13. Guest

    Chris McDonald wrote:

    > writes:
    >
    >
    > >Chris McDonald wrote:

    >
    > >> writes:
    > >>
    > >> >In the statement "a *= expression" is expression assumed to be
    > >> >parenthesized ? For example if I write "a *= b+c" is this the same
    > >> >as "a = a * (b+c)" or "a = a * b+c" ?
    > >>
    > >> Write a small C program and try it.
    > >> The learning will provide benefits.
    > >>

    >
    > >It wouldn't provide any more benefits than what I would get from
    > >a reply here. Plus experiments are a dangerous way of learning
    > >about C unless one knows beforehand that the behaviour being
    > >investigated
    > >is determined by the standard. If that's not the case then one will not
    > >know if what he observes is standard or implementation defined or
    > >undefined which just happened to work in a specific way under a
    > >specific
    > >compiler on a specific platform. For all I know , whether "expression"
    > >is
    > >parenthesized or not in "a *= expression" , is implementation defined
    > >and
    > >if one wants to achieve portability one should include parentheses in
    > >the
    > >code whenever the standard operator precedence does not give the
    > >desired
    > >result.

    >
    >
    > Sorry, politely, this is bordering on the absurd.
    > You do not trust anything you observe from experiments,
    > you do not trust anything you get from a reply here,
    > you do not trust anything you investigate to be conforming.


    I don't see how the above statements follow from what I said.

    > OK, it's your choice to be so suspicious and pedantic, but it's unclear
    > what you, or the OP, should ever trust.


    I don't feel that the words pedantic and suspicious apply at all to
    what I said.

    > Will you trust your own interpretation of the standard?
    > Will you trust anyone's interpretation of the standard?
    > And if you do trust your own or anyone else's interpretation of the standard,
    > how did you gain that trust?


    These qustions are outside the topic of the thread.

    > If every commodity compiler such as MS-Studio or gcc chose to implement
    > the above assignment in an implementation defined fashion, then how is
    > anyone to rise to the level of even a basic user?


    I suggested the possibility that the choice between *only 2*
    interpretations
    could be up to individual implementations. Even without such a
    restriction
    I don't see how it would have anything to do with one's ability to rise
    to the
    level of basic user.

    > Given the nature of the OP's original question, it's clear to anyone
    > that a basic experiment, for varying values of a, b, and c, will reveal
    > far more insight than all the anal reflection in the world.


    I can't imagine what insight you think it would offer but I'm pretty
    sure it wouldn't answer my question. In any case why don't you run
    the experiment and tell us what insight you gained ?

    Spiros Bousbouras
    , Jun 14, 2006
    #13
  14. In article <>,
    <> wrote:

    >> >A compound assignment of the form E1 op = E2 differs from the simple
    >> >assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
    >> >evaluated only once.


    >> That's not very enlightening, since it doesn't answer the question
    >> of whether E2 is b or b+c. In particular, the answer is different
    >> for a *= b,c.


    >I don't see any way to parse the expression "a *= b+c" so that E2 turns
    >out to be just b.


    There isn't. But to find that out you have to look at the grammar.
    That's why I said that the quoted sentence was not very enlightening.

    -- Richard
    Richard Tobin, Jun 14, 2006
    #14
  15. Guest

    Rafael Almeida wrote:

    > On 13 Jun 2006 15:42:52 -0700
    > wrote:
    >
    > > In the statement "a *= expression" is expression assumed to be
    > > parenthesized ? For example if I write "a *= b+c" is this the same
    > > as "a = a * (b+c)" or "a = a * b+c" ?
    > >

    > If you find this confusing why not simple use parenthesis or not use
    > the *= (and like) operator at all?


    Because I like succinctness. Plus I was curious.
    , Jun 14, 2006
    #15
  16. Guest

    Keith Thompson wrote:

    > writes:
    > > In the statement "a *= expression" is expression assumed to be
    > > parenthesized ? For example if I write "a *= b+c" is this the same
    > > as "a = a * (b+c)" or "a = a * b+c" ?

    >
    > All assignment operators, including "*=" and ordinary "=", have the
    > same precedence.
    >
    > Just as "a = b + c" means "a = (b + c)", "a *= b + c" means "a *= (b + c)".
    >
    > Your C textbook should have an operator precedence table or equivalent.


    Well , I saw my question as one about semantics rather than operator
    precedence.
    , Jun 14, 2006
    #16
  17. On 13 Jun 2006 17:15:17 -0700
    wrote:

    > Rafael Almeida wrote:
    > > If you find this confusing why not simple use parenthesis or not use
    > > the *= (and like) operator at all?

    >
    > Because I like succinctness. Plus I was curious.
    >


    I rather like legibility. Being curious is ok, though.
    Rafael Almeida, Jun 14, 2006
    #17
  18. On 13 Jun 2006 17:20:13 -0700
    wrote:

    >
    > Keith Thompson wrote:
    >
    > > All assignment operators, including "*=" and ordinary "=", have the
    > > same precedence.
    > >
    > > Just as "a = b + c" means "a = (b + c)", "a *= b + c" means "a *= (b + c)".
    > >
    > > Your C textbook should have an operator precedence table or equivalent.

    >
    > Well , I saw my question as one about semantics rather than operator
    > precedence.
    >

    Are you saying keith didn't answer your question?
    Rafael Almeida, Jun 14, 2006
    #18
  19. writes:
    > Keith Thompson wrote:
    >> writes:
    >> > In the statement "a *= expression" is expression assumed to be
    >> > parenthesized ? For example if I write "a *= b+c" is this the same
    >> > as "a = a * (b+c)" or "a = a * b+c" ?

    >>
    >> All assignment operators, including "*=" and ordinary "=", have the
    >> same precedence.
    >>
    >> Just as "a = b + c" means "a = (b + c)", "a *= b + c" means "a *= (b + c)".
    >>
    >> Your C textbook should have an operator precedence table or equivalent.

    >
    > Well , I saw my question as one about semantics rather than operator
    > precedence.


    No, it was a question about operator precedence (actually about how
    expressions are parsed, since the standard doesn't talk about
    precedence as such). The semantics of the expression follow from the
    way it's parsed (and from the semantics of the operations themselves).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jun 14, 2006
    #19
  20. Guest

    Richard Tobin wrote:

    > In article <e6nj7r$p5t$>,
    > Giannis Papadopoulos <> wrote:
    >
    > >>> A compound assignment of the form E1 op = E2 differs from the simple
    > >>> assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
    > >>> evaluated only once.

    >
    > >> That's not very enlightening, since it doesn't answer the question
    > >> of whether E2 is b or b+c. In particular, the answer is different
    > >> for a *= b,c.

    >
    > >It says (E2) so why should it be further clarified?

    >
    > Your reasoning would lead to the (wrong) conclusion that a *= b,c is
    > equivalent to a = a * (b,c).
    >
    > Yes, you put parentheses around E2, but what *is* E2? Is it b
    > or b op c?


    In the general case , E2 would be the right operand of the *= operator.
    So in the expression "a *= b,c" we use operator precedence to decide
    that the right operand of the *= operator is b and combining that
    with what Giannis said we conclude that "a *= b" is the same as
    "a = a * (b)".

    > The standard answers the question by means of the sequence of
    > productions in section 6.5. a *= b + c is parsed as a *= (b + c)
    > because the the right operand of an assignment operator can be an
    > additive expression, which b + c is; whereas the left operand of an
    > additive expression must be an additive expression, which a *= b
    > isn't.


    Actually this is something which does not answer my question. I *knew*
    when I made the opening post that "a *= b + c" is parsed as "a *= (b +
    c)"
    ie that the right hand operand of *= is "b+c" but I wasn't completely
    certain how the right hand operand is to be used to alter the value of
    the
    left hand operand. See also the comment below.


    Richard Tobin wrote:

    > In article <>,
    > <> wrote:
    >
    > >In the statement "a *= expression" is expression assumed to be
    > >parenthesized ? For example if I write "a *= b+c" is this the same
    > >as "a = a * (b+c)" or "a = a * b+c" ?

    >
    > The latter would only be plausible if *= was some kind of macro. If
    > you could define infix macros and did
    >
    > #define-infix x*=y x=x*y
    >
    > then a*=b+c might expand to a=a*b+c.
    >
    > But C operators are not like macros. The only question is the
    > relative precedence of *= and +. It will either be
    >
    > (a *= b) + c, which is equivalent to (a = a*b) + c,
    > or
    > a *= (b + c), which is equivalent to a = a * (b+c).
    >
    > In fact, it's a = a * (b + c), because the assignment operators all
    > have lower precedence than the arithmetic operators.


    Yes , after the explanations from various people I see now that the
    alternative I had in mind was rather implausible. But I'm glad I
    verified it.
    , Jun 14, 2006
    #20
    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. Alex Vinokur
    Replies:
    4
    Views:
    3,045
    Peter Koch Larsen
    Nov 26, 2004
  2. Shalafi
    Replies:
    2
    Views:
    349
    Ben Pfaff
    Feb 13, 2005
  3. Alex Vinokur
    Replies:
    3
    Views:
    5,017
    Jeff Schwab
    Mar 20, 2005
  4. Bo Peng
    Replies:
    31
    Views:
    800
    Ron Adam
    Jun 30, 2005
  5. Hicham Mouline
    Replies:
    2
    Views:
    691
    Juha Nieminen
    Sep 1, 2009
Loading...

Share This Page