This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Volatile MEMs in statement expressions and functions inlined astrees


>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:

> In article <wvl1yi7vna1.fsf@prospero.cambridge.redhat.com> 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
read.

> although I personally do not really see why C++ would make it an
> lvalue.

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

  http://wwwold.dkuug.dk/JTC1/SC22/WG21/docs/cwg_active.html#222

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.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]