Using the same Reference for a new object

Question

While searching for some loosely related stuff I bumped into this quote:

And a reference can outlive an object and be used to refer to a new object created at the same address.

From this answer.

Now, I've always known and worked by references being immutable, initialized once and all that. Reading the above quote, by someone likely more experienced than I am, got me wondering if I'm missing something.

Was that sentence meant to be for the sake of completeness but practically inapplicable?

Is there some pattern or circumstance where people would go through the pain of landing a new object of the same type in a specific memory address just to to do a switcheroo for a reference? (which seems supremely dangerous to me, not to mention convoluted at the best of times).

Answer 1

Under the covers, references are little more than auto-dereferencing pointers, so they suffer from some of the same issues as pointers. References can be stale, just like pointers can. The memory referred to by a reference can be reused by other objects, just as it can for the memory referred by by a pointer. I think that's all the statement in question is trying to say.

Would a sane programmer intentionally leverage this? Not likely, nor do I think the comment was suggesting that you attempt to do so (although technically it is possible, using placement new). I think it was more to prevent people from thinking along the lines of managed languages, where the mere existence of a reference is enough to keep an object alive.

Answer 2

The problem of dangling references is essentially the same as the problem of dangling pointers.

For example, two functions

int &GetReference()
{
    int x;    //  local variable

    return x;
}

int *GetPointer()
{
    int x;

    return &x;
} 

cause exactly the same problems for the caller if the returned reference is used, or the pointer dereferenced.

int &r = GetReference();
int *p = GetPointer();

r = 52;
*p = 42;

Both of the assignments exhibit undefined behaviour, since the variables named x (within the two functions) no longer exist, as far as the program is concerned. However, the code can SEEM to work correctly.

The same can happen with creating dangling references or pointers by releasing dynamically allocated memory (free() in C, operator delete in C++).

If other code (eventually) uses that memory (e.g. to represent another variable, to represent an unrelated object), that reference or pointer does often have access to whatever is at that memory location. That can give spurious problems of the value changing (which can give surprises for code using the reference, or for the unrelated code that finds variables or objects being changed).

It is not something to aspire to, or to use, practically. It is a dangerous program flaw that is often very hard to fix or debug - because it provides a path for two completely unrelated sections of code to affect data used by the other.

Fortunately, modern compilers usually (if configured to give maximum warning levels) do give warnings about a lot of suspicious constructs (e.g. returning a pointer or reference to a local variable).

Answer 3

Here's the full paragraph from the C++ Standard, which I was paraphrasing:

If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if:

• the storage for the new object exactly overlays the storage location which the original object occupied, and
• the new object is of the same type as the original object (ignoring the top-level cv-qualifiers), and
• the type of the original object is not const-qualified, and, if a class type, does not contain any non-static data member whose type is const-qualified or a reference type, and
• the original object was a most derived object (1.8) of type T and the new object is a most derived object of type T (that is, they are not base class subobjects).

"A new object is created at the storage location" is certainly the effect of placement-new, as midor observes.

Answer 4

I think this could only make sense in the context of a placement new. If the object the reference points to was created with placement new, it should be possible to destroy the object and create a new object in the same spot with placement new again. I don't see any immediate reason not to use a pointer instead at the moment though.