182
votes

Why does this:

#include <string>
#include <iostream>
using namespace std;

class Sandbox
{
public:
    Sandbox(const string& n) : member(n) {}
    const string& member;
};

int main()
{
    Sandbox sandbox(string("four"));
    cout << "The answer is: " << sandbox.member << endl;
    return 0;
}

Give output of:

The answer is:

Instead of:

The answer is: four

6
And just for more fun, if you had written cout << "The answer is: " << Sandbox(string("four")).member << endl;, then it would be guaranteed to work.Roger Pate
@RogerPate Could you explain why?Paolo M
For someone who's curious, example Roger Pate posted works because string("four") is temporary and that temporary is destroyed at the end of full expresion, so in his example when SandBox::member is read, temporary string is still alive.PcAF
The question is: Since writing such classes is dangerous, is there a compiler warning against passing temporaries to such classes, or is there a design guideline (in Stroustroup?) that prohibits writing classes that store references? A design guideline to store pointers instead of references would be better.Grim Fandango
FWIW, I'm not able to reproduce the output of "The answer is:" on GCC or MSVC 2013. Does this typically need -O3 or something for it to show itself?jrh

6 Answers

177
votes

Only local const references prolong the lifespan.

The standard specifies such behavior in §8.5.3/5, [dcl.init.ref], the section on initializers of reference declarations. The reference in your example is bound to the constructor's argument n, and becomes invalid when the object n is bound to goes out of scope.

The lifetime extension is not transitive through a function argument. §12.2/5 [class.temporary]:

The second context is when a reference is bound to a temporary. The temporary to which the reference is bound or the temporary that is the complete object to a subobject of which the temporary is bound persists for the lifetime of the reference except as specified below. A temporary bound to a reference member in a constructor’s ctor-initializer (§12.6.2 [class.base.init]) persists until the constructor exits. A temporary bound to a reference parameter in a function call (§5.2.2 [expr.call]) persists until the completion of the full expression containing the call.

30
votes

Here's the simplest way to explain what happened:

In main() you created a string and passed it into the constructor. This string instance only existed within the constructor. Inside the constructor, you assigned member to point directly to this instance. When when scope left the constructor, the string instance was destroyed, and member then pointed to a string object that no longer existed. Having Sandbox.member point to a reference outside its scope will not hold those external instances in scope.

If you want to fix your program to display the behavior you desire, make the following changes:

int main()
{
    string temp = string("four");    
    Sandbox sandbox(temp);
    cout << sandbox.member << endl;
    return 0;
}

Now temp will pass out of scope at the end of main() instead of at the end of the constructor. However, this is bad practice. Your member variable should never be a reference to a variable that exists outside of the instance. In practice, you never know when that variable will go out of scope.

What I recommend is to define Sandbox.member as a const string member; This will copy the temporary parameter's data into the member variable instead of assigning the member variable as the temporary parameter itself.

5
votes

Technically speaking, this program isn't required to actually output anything to standard output (which is a buffered stream to begin with).

  • The cout << "The answer is: " bit will emit "The answer is: " into the buffer of stdout.

  • Then the << sandbox.member bit will supply the dangling reference into operator << (ostream &, const std::string &), which invokes undefined behavior.

Because of this, nothing is guaranteed to happen. The program may work seemingly fine or may crash without even flushing stdout -- meaning the text "The answer is: " would not get to appear on your screen.

2
votes

It's clear from the other answers that class members don't prolong the life of a temporary beyond the constructor call. There are cases though were your API can "safely" assume that all const& objects passed to a class won't be temporaries, but references to well scoped objects.

If you don't want to create copies, what can you do to ensure UB doesn't creep into your code? The best tool you have is to safeguard the assumption that std::string const& passed to the constructor are not temporaries, by declaring as deleted the overload that accepts such temporaries:

#include <string>
#include <iostream>
using namespace std;

class Sandbox
{
public:
    Sandbox(const string& n) : member(n) {}
    
    Sandbox(string&&) = delete;
    // ^^^ This guy ;) 

    const string& member;
};

int main()
{
    Sandbox sandbox(string("four"));
    // Detect you're trying ^^^ to bind a 
    // reference to a temporary and refuse to compile

    return 0;
}

Demo

0
votes

Because your temporary string went out of scope once the Sandbox constructor returned, and the stack occupied by it was reclaimed for some other purposes.

Generally, you should never retain references long-term. References are good for arguments or local variables, never class members.

0
votes

you're referring to something which has vanished. The following will work

#include <string>
#include <iostream>

class Sandbox
{

public:
    const string member = " "; //default to whatever is the requirement
    Sandbox(const string& n) : member(n) {}//a copy is made

};

int main()
{
    Sandbox sandbox(string("four"));
    std::cout << "The answer is: " << sandbox.member << std::endl;
    return 0;
}