This is the mail archive of the 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

On 14 Dec 2001, Alexandre Oliva wrote:

> On Dec 14, 2001, Linus Torvalds <> wrote:
> > The fact is, C++ does NOT "create" addresses for true rvalues.
> Guess what: it does.

Not in general.

There are "gray areas", but rvalues in general do not have addresses, and
the compiler will _not_ generate them. I already gave the simple example
of the obvious "pp = &(p+1)" etc.

Does C++ have some magic special cases? It sure as hell does. But you
cannot create an address for most rvalues: no compiler is able to create a
valid address for simple expressions etc.

In particular, C++ structure return is implemented as an implied "call by
reference" where the _caller_ will pass the callee a temporary variable
that does not actually exist on a source level, and the callee will return
the value in that variable (not "that" - "this").

Now, that return value is not really an lvalue, but it's actually
addressable by the compiler in the caller, because of the implied temp
variable. At least that's how I understand it (and I'll freely admit that
my understanding of all the magic C++ behaviour is very very limited: it's
a rather complex language).

COULD it be a real lvalue? Yes. I think that special case is actually a
syntactic one, not a fundamental issue. Not making that addressable
variable a lvalue means that the compiler on a syntactic level actually
disallows you from taking the address of the temporary object.

(I actually _did_ mention the magic C++ "pass by reference" in my email,
see the last incoherent comments on lvalue vs rvalue).


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