Related articles |
---|
m68k gcc/egcs question zoltan@bendor.com.au (Zoltan Kocsi) (1999-09-20) |
Re: m68k gcc/egcs question davidwilliams@ozemail.com.au (David Williams) (1999-09-24) |
Re: m68k gcc/egcs question mrs@kithrup.com (1999-09-24) |
Re: m68k gcc/egcs question jejones@microware.com (James Jones) (1999-09-27) |
Re: m68k gcc/egcs question albert@korppi.cs.tut.fi (1999-09-28) |
Re: m68k gcc/egcs question zalman@netcom3.netcom.com (Zalman Stern) (1999-10-01) |
Re: m68k gcc/egcs question zoltan@bendor.com.au (Zoltan Kocsi) (1999-10-01) |
Re: m68k gcc/egcs question zalman@netcom12.netcom.com (Zalman Stern) (1999-10-03) |
Re: m68k gcc/egcs question graham@barnowl.demon.co.uk (Graham Murray) (1999-10-03) |
From: | Zoltan Kocsi <zoltan@bendor.com.au> |
Newsgroups: | comp.sys.m68k,comp.compilers |
Date: | 1 Oct 1999 10:10:40 -0400 |
Organization: | Bendor Research Pty. Ltd. |
References: | 99-09-078 99-09-103 |
Keywords: | C++ |
mrs@kithrup.com (Mike Stump) writes:
> a=b=c means fetch c, store into b, fetch b, store into a. It does not
> mean fetch c, and store into both a and b.
Yes, reading the exact wording indeed means that.
> Let me quote from ANSI C++:
>
> 5.17 Assignment operators [expr.ass]
>
> 1 There are several assignment operators, all of which group right-to-
> left. All require a modifiable lvalue as their left operand, and the
> type of an assignment expression is that of its left operand.
So far it is simple and clear.
> The
> result of the assignment operation is the value stored in the left
> operand after the assignment has taken place; the result is an lvalue.
As you have stated, it says that the result is an lvalue, therefore it
must be a reference to the left hand storage rather than its content
directly.
This will of course turn
a = b = c;
as you've said to
b = c;
a = b;
On the other hand, what if we have pointers ?
*a = *b = *c;
should it be turned to
*b = *c;
*a = *b;
in which case, if b itself is volatile it should result to a re-read of b.
Alternatively, the *a = *b = *c; can be transformed to
non_volatile typeof( b ) temp;
temp = b;
*temp = *c;
*a = *temp;
which, incidently, is what GCC does.
> No, this is not a dangerous assumption. The asumption is that you
> know the rules that gcc uses for volatile.
OK, I deserved that.
> Also if someone can state what c9x says about this, that would be
> great.
It says this:
An assignment operator stores a value in the object designated by
the left operand. An assignment expression has the value of the left
operand after the assignment, but is not an lvalue.
(Now this is interesting - it is actually a change from what you've quoted
and makes the whole issue less clear.)
The type of an assignment expression is the type of the left operand
unless the left operand has qualified type, in which case it is the
unqualified version of the type of the left operand. The side effect
of updating the stored value of the left operand shall occur between
the previous and the next sequence point.
> I think that the language standards should answer these types
> of questions in a complete and unambiguous way.
It should, shouldn't it ...
> I am sorry that they don't. Petition your languages standards to
> do this.
I'll try :-)
Regards,
Zoltan
| Zoltan Kocsi | I don't believe in miracles |
| Bendor Research Pty. Ltd. | but I rely on them. |
Return to the
comp.compilers page.
Search the
comp.compilers archives again.