Question about the *= (and similar) operator

S

spibou

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" ?
 
C

Chris McDonald

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

spibou

Chris said:
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
 
G

Giannis Papadopoulos

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

Richard Tobin

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
 
R

Richard Tobin

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" ?
[/QUOTE]
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
 
R

Rafael Almeida

On 13 Jun 2006 15:42:52 -0700
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?
 
G

Giannis Papadopoulos

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[/QUOTE]

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

Chris McDonald

Chris McDonald wrote:
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.
 
S

spibou

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.[/QUOTE]

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

Keith Thompson

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

Richard Tobin

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.
[/QUOTE]
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
 
S

spibou

Chris said:
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
 
R

Richard Tobin

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.
[/QUOTE]
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
 
S

spibou

Rafael said:
On 13 Jun 2006 15:42:52 -0700

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

spibou

Keith said:
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.
 
R

Rafael Almeida

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.
[/QUOTE]

I rather like legibility. Being curious is ok, though.
 
R

Rafael Almeida

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.
[/QUOTE]
Are you saying keith didn't answer your question?
 
K

Keith Thompson

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).
 
S

spibou

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?[/QUOTE]

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 said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top