This is the mail archive of the
mailing list for the GCC project.
Re: Volatile MEMs in statement expressions and functions inlined astrees
- From: Jason Merrill <jason at redhat dot com>
- To: Linus Torvalds <torvalds at transmeta dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 07 Dec 2001 15:03:04 +0000
- Subject: Re: Volatile MEMs in statement expressions and functions inlined astrees
- References: <Pine.LNX.firstname.lastname@example.org>
>>>>> "Linus" == Linus Torvalds <email@example.com> writes:
> In article <firstname.lastname@example.org> you write:
>> However, the C++ standard says
>> 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.
>> This seems a pretty clear distinction to me; in C++, *q should be read
>> after the store. In C, it should not.
> I don't think you can really strictly argue either way, and it will
> probably depend on just how people read it.
> When I hear that the result is "... the value stored in the left
> operand ...", I personally would understand it to be that it is the
> "value stored", ie it's not the "value reloaded".
I would agree with that interpretation, were it not for the lvalue bit.
Indeed, my point is that that's the difference between C and C++.
> I don't see why the lvalue/rvalue thing should matter
Because an lvalue is a reference to an object. Using that reference on the
right side of an assignment means converting it to an rvalue, which does a
> although I personally do not really see why C++ would make it an
Many expressions which yield an rvalue in C were changed to yield an lvalue
in C++ because C++ adds the concept of reference type. I think it's
reasonable to argue that using 'a = b' in an expression should have the
same effect as using '(a = b, a)', which should have the same effect as
doing the assignment, then just using 'a'. In any case, that's what the
language semantics have always been.
There has actually been a fair amount of discussion of the issue of
lvalue-returning operators and abstract machine semantics in the C++
committe recently. See
for an account. The consensus seems to be that the semantics are indeed
different, that it wasn't an intentional change, but that we don't want
to make a special case for it. So we're adding a sequence point between
performing the assignment and yielding the result.