14

Trying to learn lvalues, rvalues and memory allocation for them. So with a lot of learning materials there is a bit of chaos.

An rvalue is a value that needs to exist only in bounds of a expression where it was created (until C++11 at least). So it has an address and block of memory that it occupies. But by definition we cannot get an address of rvalue, because it is a temporary object in contrast to an lvalue. But even before C++11 we were able to get an address of rvalue by returning it from a function and saving it into a const reference type (uh, I guess not an address but a value).

So, more precisely, how does rvalue allocation work? For how long does the program or OS really remember that place of memory where the rvalue was created and marked as allocated and another object cannot take its place?

How I see it, now rvalues are stored just like lvalues but we simply have other rights to access them. And they have other types of deallocation - for lvalues going out of scope, for rvalues may be optimized by existence in bounds of expression or until there is no more links to it.

Drax
  • 12,682
  • 7
  • 45
  • 85
Il'ya Zhenin
  • 1,272
  • 2
  • 20
  • 31
  • 8
    lvalues and rvalues are expression categories. They don't use any storage. What does use storage is *objects*. (and sometimes, references). You seem to be writing "rvalue" when in fact you mean "temporary object". – M.M Dec 11 '15 at 10:32
  • I don't think that rvalues need to have an address at all. They can just be evaluated in registers. –  Dec 11 '15 at 10:32
  • 1
    @M.M This should be *The* answer – Ivan Aksamentov - Drop Dec 11 '15 at 10:53
  • @Drop well - I think OP means to ask about *temporary objects* and my comment doesn't answer that, it was just clearling up the terminology – M.M Dec 11 '15 at 11:08

2 Answers2

12

Short answer: it's implementation dependent.

The main reasoning behind this is as always freedom for the compiler to improve performances of your code. A more concrete way to understand this is to remember that a value can be stored in a register of your CPU and never actually be in your memory which more or less means that the value has no address. I won't bet everything i have on it but this is probably one of the main reasons why "we cannot get an address of an rvalue".

In a more general way since an rvalue is semantically temporary it is more likely to be put in temporary places or optimised in a way where it cannot easily be mapped to an address and even if it can that would be counter productive in terms of performance.

Drax
  • 12,682
  • 7
  • 45
  • 85
9

Conceptually, rvalues live on the "stack". If you get to their address, it is conceptually an address somewhere on the stack. If the address isn't taken at all, the entity may never really come into existence as long as the compiler sets up the correct instructions to have it appear as if it were created.

Even if the entity is really created where exactly it resides depends on various things and it may even end up not being on the stack at all: it may be in the current stack frame but it may also be an other stack frame or in some destintation if the rvalue ends up being copied/moved there and the compiler does copy-elision. If the rvalue ends up being bound to a const& it may also reside somewhere else than it would if it didn't.

The life-time of the rvalue is bound by the language rules. How that is actually implemented is pretty much up to the compiler and/or the ABI it adheres to.

Dietmar Kühl
  • 150,225
  • 13
  • 225
  • 380