Item 17: Store newed objects in smart pointers in standalone statements.
Suppose we have a function to reveal our processing priority and a second function to do some processing on a dynamically allocated Widget in accord with a priority:
int priority();
void processWidget(std::tr1::shared_ptr<Widget> pw, int priority);
Mindful of the wisdom of using objects to manage resources (see Item 13), processWidget uses a smart pointer (here, a TR1::shared_ptr) for the dynamically allocated Widget it processes.
Consider now a call to processWidget:
processWidget(new Widget, priority());
Wait, don't consider that call. It won't compile. tr1::shared_ptr's constructor taking a raw pointer is explicit, so there's no implicit conversion from the raw pointer returned by the expression "new Widget" to the TR1::shared_ptr required by processWidget. The following code, however, will compile:
processWidget(std::tr1::shared_ptr<Widget>(new Widget), priority());
Surprisingly, although we're using object-managing resources everywhere here, this call may leak resources. It's illuminating to see how.
Before compilers can generate a call to processWidget, they have to evaluate the arguments being passed as its parameters. The second argument is just a call to the function priority, but the first argument, ("std::tr1::shared_ptr<Widget>(new Widget)") consists of two parts:
Before processWidget can be called, then, compilers must generate code to do these three things:
C++ compilers are granted considerable latitude in determining the order in which these things are to be done. (This is different from the way languages like Java and C# work, where function parameters are always evaluated in a particular order.) The "new Widget" expression must be executed before the tr1::shared_ptr constructor can be called, because the result of the expression is passed as an argument to the tr1::shared_ptr constructor, but the call to priority can be performed first, second, or third. If compilers choose to perform it second (something that may allow them to generate more efficient code), we end up with this sequence of operations:
Call the tr1::shared_ptr constructor.
But consider what will happen if the call to priority yields an exception. In that case, the pointer returned from "new Widget" will be lost, because it won't have been stored in the TR1::shared_ptr we were expecting would guard against resource leaks. A leak in the call to processWidget can arise because an exception can intervene between the time a resource is created (via "new Widget") and the time that resource is turned over to a resource-managing object.
The way to avoid problems like this is simple: use a separate statement to create the Widget and store it in a smart pointer, then pass the smart pointer to processWidget:
std::tr1::shared_ptr<Widget> pw(new Widget); // store newed object
// in a smart pointer in a
// standalone statement
processWidget(pw, priority()); // this call won't leak
This works because compilers are given less leeway in reordering operations across statements than within them. In this revised code, the "new Widget" expression and the call to the TR1::shared_ptr constructor are in a different statement from the one calling priority, so compilers are not allowed to move the call to priority between them.
| 
