Smart Pointers Reloaded (III): Construction

Here's the motivator of the day: "Being really really good at C++ is like being really really good at using rocks to sharpen sticks." We found this on the Net, and quote it unattributed to protect the innocent (as if you haven't heard of Google). But fear not: Psychologists say that the best compliments start with a negative, and end up with a positive such as "...but we're in the Stone Age of computing anyway." And then you think, hey, he said "really really good."

We hope this quote didn't lower your morale in the least, because now we're going to teach how to use this silex to...pardon, we'll talk about dealing with exceptions that occur during object initialization. More precisely, we'll present the fascinating saga of smart_ptr initialization, a story that has important teachings for any generic design — and policy-based classes in particular.

Delayed Acknowledgment

Coauthoring is fun, but has surprising drawbacks. One such drawback, for example, is that coauthors tend to leave certain obvious tasks to one another, to the extent that those tasks never get done. Mind you, neglect happens when you write alone as well, but at least you feel more stressed when you're alone. Really, coauthorship can bring some sense of false security with it — just like programming with exceptions sometimes does.

This is exactly what happened with our December 2003 column. Before submitting it, we sent the article out for review to David Abrahams — the one whose name the C++ community fondly put in "the Abrahams exception safety guarantees" [1,4]. Through a long and substantive e-mail exchange, David made many great points and prompted us to change our draft in many meaningful ways. What then happened is that we both left to each other the job of acknowledging in writing David Abrahams' contribution. So we do the best we now can — thanks David for your contribution to our last column and this one, and please accept our apologies. We'd also like to thank George Cristea and Christian Vlasceanu for reviewing this article.

The Timeless Art of Initialization

Resource Acquisition Is Initialization (RAII) is a great concept with a bad acronym (how do you pronounce it, "are-ay-eye-eye" or the equally awkward "are-ay-double-eye"?) and is all about those objects that nicely grab some resource in their constructor and free it in their destructor. Then, dealing with resource management reduces to scoping those objects properly.

In "Smart Pointers Reloaded (I)" [2], we mentioned an exception safety bug in smart_ptr, and that Dave Held fixed it with helpful criticism from the Boost community (and especially, again, David Abrahams). Just like the size optimization, what started out as an innocuous discussion turned into a significant modification of smart_ptr's implementation.

The original smart_ptr took the traditional route of freeing the resource only when the ownership policy deemed it was okay. However, in the default reference-counted configuration, if the reference-counted constructor threw an exception, the passed-in resource would be leaked.

Listing 1 shows the original Loki code. As you can see, if ref_counted::ref_counted() throws, smart_ptr(stored_type p) leaks p because ~smart_ptr() is never called. (By definition, an object's destructor is called only if it has been fully constructed.) Curiously, the RAII idiom fails to ensure the exception safety for which it is typically known. However, the failure is not in RAII itself, but...really, where is the problem? Whose constructor is it anyway? On the face of it, you just carefully write smart_ptr's constructor to face exceptions properly, don't you?

It turns out you can't simply use try/catch in the constructor to detect initialization failures, which is a most puzzling realization. Yes, we have try, we have catch, but we simply cannot detect and properly handle exceptions in constructors [5]. Let's use a simple example to illustrate this point — a class A containing two Bs:

<b>class A {
   B b1_;
   B b2_;
public:
   A()
   try // constructor try block
   : b1_(</b>"<b>hello</b>"<b>), b2_(</b>"<b>world</b>"<b>)
   {
      ... constructor body ...
   }
   catch (...) {
      // and this is its catch
   ...
   }
};</b>

A's constructor uses the lesser known function try block feature that allows catching whatever exception b1_ or b2_'s constructors might throw. This is as much trying as we can do; we could honestly say that we've thrown everything we have at the problem. Yet we haven't solved it. Inside the catch block, our code can't tell which of b1_ and b2_ failed to initialize!

If you were thinking you really can do what you want in C++, it's about time to disabuse yourself of that illusion. If, in addition, you are the philosopher type, you might speculate that the odd constructor syntax and semantics came up and froze before exceptions turned out to be so darn important. Continuing on the musing route, one possible fix close to the current syntax would be to allow each member initializer to have its own try block:

<b>// Warning: this is NOT C++
class A {
   B b1_;
   B b2_;
public:
   A()
   : try b1_(</b>"<b>hello</b>"<b>)
     catch(...) { ... b1_ failed ... }
   , try b2_(</b>"<b>world</b>"<b>)
     catch(...) { ... b2_ failed ... }
   {
      ... constructor body ...
      // only executes if none failed
   }
};</b>

Of course, the best is to design the constructor syntax and semantics taking exceptions into account from the get-go. To conclude said musings, it is a mild disappointment to see that the recently added function try block, after passing through the whole Scylla and Charybdis of standardization, provides so little functionality.

A fix within the current language would be to add a new member and to use a constructor of B that takes an argument, something like this:

<b>class A {
   int tracker_;
   B b1_;
   B b2_;
public:
   A()
   try
   : tracker_(0)
   , b1_((tracker_ = 1, </b>"<b>hello</b>"<b>))
   , b2_((tracker_ = 2, </b>"<b>world</b>"<b>))
   {
      assert(tracker_ == 2);
      ... constructor body ...
   }
   catch(...) {
      if (tracker_ == 0) {
        ... none initialized ...
      } else {
        ... only b1_ initialized ...
      }
   }
};</b>

The extra set of parentheses in the initialization of b1_ and b2_ forces the operator semantics for the comma (so that the compiler doesn't think you're passing two arguments to B::B). What exposes this hack is (1) if you want to call a parameterless constructor for B, you're left out in the cold; (2) you need to use a nonstatic member for what's essentially a stack variable used only during construction; (3) you have the fragile requirement that tracker_ must appear before any other member in A's definition. You can continue hacking away at it by making tracker_ static, but all of the sudden you now have multithreading-related problems. tracker_ belongs to the stack, and there's no way to put it there.

Or there is. Consider this:

<b>class A {
   B b1_;
   B b2_;
public:
   A(int tracker = 0)
   try
   : b1_((tracker = 1, </b>"<b>hello</b>"<b>))
   , b2_((tracker = 2, </b>"<b>world</b>"<b>))
   {
      assert(tracker == 2);
      ... constructor body ...
   }
   catch(...) {
      if (tracker == 0) {
         ... none initialized ...
      } else {
         ... only b1_ initialized ...
      }
   }
};</b>

So now the tracker is indeed on the stack, in the form of an additional parameter of A's constructor. That extra parameter doesn't bother clients much because it has a default value. But client code that wrongly initializes tracker still compiles and runs, to everyone's confusion:

<b>A a(3); // oopsies</b>

Overloading of different constructors would only make things worse. But, as the guy with a chance in a million said, there is hope. Let's make tracker of a private type:

<b>class A {
   B b1_;
   B b2_;
   enum tracker_type = { NONE, B1, B2 };
public:
   A(tracker_type tracker = NONE)
 try
   : b1_((tracker = B1, </b>"<b>hello</b>"<b>))
   , b2_((tracker = B2, </b>"<b>world</b>"<b>))
   {
      assert(tracker == B2);
      ... constructor body ...
   }
   catch(...) {
      if (tracker == NONE) {
        ... none initialized ...
      } else {
        ... only b1_ initialized ...
      }
   }
};</b>

Now the client code, no matter what it tries, can't explicitly pass a tracker to A's constructor. We effectively made tracker a stack variable that just happens to sit in A::A's parameter list for the quirky reasons just mentioned. If \code{type_tracker} is a full-fledged class with constructors and destructors, you can track \code{A}'s construction quite effectively with it.

The disadvantage of this "construction tracker" idiom remains that it can't cope with parameterless constructors. The code that updates tracker must "parasite" some argument passed to each member variable of interest.

The resource_manager Class

The same problem can be solved another way by going the RAII route, without any try in sight — and actually, that's how smart_ptr currently tracks its own construction. We move the resource tracking logic to the individual policies. We do so by letting storage_policy always free the passed-in resource, unless someone "higher up" tells it not to (because of ref-counting or some other strategy). The bits of code relevant to this new strategy are:

<b>scalar_storage::~scalar_storage()
{ boost::checked_delete(pointee_); }
void scalar_storage::release()
{ pointee_ = 0; }
ref_counted::~ref_counted()
{ delete count_; }
void ref_counted::reset(ref_counted& sp) {
   if (sp.count_) {
       — *sp.count_;
   sp.count_ = 0;
  }
}</b>

Now smart_ptr never leaks resources. In fact, it's so frenetic about not leaking that it falls into the other extreme — it deletes too often. Most of the time it is the ownership policy that decides whether deletion takes place. To prevent that and take control of deletion, what we want is to call scalar_storage::release() during smart_ptr's destruction, which causes ~scalar_storage() to delete the null pointer instead. So instead of stealing candy from a baby, you have the baby give the candy to another baby, and you take the candy from the second baby on your way out; while doing that, you leave the second baby with just a candy wrapper (the null pointer). The advantage is that should any quarrel arise between the two babies in the first stage, you don't get your hands sticky — and the babies won't leak.

Let's recap the logic. We need to do this during initialization:

1. Storage gets created before ownership, because otherwise we'd have to handle the awkwardness of an ownership policy that owns nothing. (We've tried that and it wasn't cool.)

2. If the storage policy is successfully created but the ownership policy is not (throws), the storage policy must destroy the resource because there's no ownership policy to take care of it.

3. As soon as the ownership policy is successfully created, it takes, well, ownership of the resource. The storage policy must destroy the resource only if the ownership policy agrees with that.

Okay, where do we implement that sleight of hand? It's really simple: The lifetimes of the storage policy and the ownership policy are interdependent, and as such we aggregate them (and only them) into an object with its own destructor. That object is resource_manager.

The resource_manager class connects the storage policy and ownership policy during destruction. True, it would be awkward to create a whole new class just to provide one function. However, you might recall from the first article in this series that we added a mechanism to only inherit from nonempty base classes, thus avoiding size bloat due to multiple inheritance. The structure of this mechanism makes it easy and elegant to replace one of the classes with our resource manager, as in Listing 2. Note that resource_manager's destructor is just the original smart_ptr destructor moved to a position where it can be effective. Also note that the logic has been reversed because of the babies and the candy. The original smart_ptr::~smart_ptr() was saying: "If ownership_policy says it's okay to free the resource, have storage_policy do so." But resource_manager::~resource_manager() says: "If ownership_policy will not let go of the resource, tell storage_policy to let go of its reference to the resource."

Things turned out quite nicely, but remember this: smart_ptr may be smart, but it's only as smart as its policies. When you define your own storage and ownership policies, follow these guidelines, which we believe are entirely reasonable:

• The destructure of the storage policy must always dispose of its held resource.
• The storage policy must implement release() in such a way that it renders the destructor a no-op (a good example of a combo is a release() that assigns NULL to the stored pointer, and a destructor that deletes the pointer (delete is a do-nothing on null pointers).

• The ownership policy, once successfully constructed, must be able to properly decide on the lifetime of the owned resource. There's no such thing as a nonfunctioning ownership.

• The ownership policy manages its own private resources (that is, counter).

And you know what the nicest part is? Orthogonality. Each of the two policies takes care of its own exception safety; there's no correlation you need to maintain between the exception safety of the storage policy and that of the ownership policy.

Exception Algorithm in Action

In February 2003, we introduced an informal algorithm for computing the exception safety of a function. Now that we have seen part of smart_ptr's exception interface, we will apply that algorithm to one of the functions in smart_ptr. Since the modularity of smart_ptr's design results in a lot of short, mostly trivial functions, we'll take a look at the most complex function in the library (at least from an exception analysis point of view): smart_ptr::release().

<b>1 void release(this_type& sp, stored_type& p) {
2    checking_policy::on_release(get_impl(sp));
3    ownership_policy::on_release(sp);
4    p = get_impl_ref(sp);
5    get_impl_ref(sp) =
6      storage_policy::default_value();
7    ownership_policy::reset(sp);
8  }</b>

Recall that we start out with the state tuple: <safety : nothrow,purity : true, exception_ set : 0,caught_set : 0>. The first call to analyze is get_impl(). Since get_impl() is defined to be nothrow, we need not consider caught set for this operation. Further, Purity(get_ impl()) == true and Safety(get_impl()) == nothrow, so we can move on to the next operation, which is checking_ policy::on_release().

Now, checking_policy::on_release() may throw, which is the whole point of a checking policy. Also, it is not smart_ptr's responsibility to deal with that exception (or any exception thrown by a policy), so caught set remains empty for the duration of the analysis. Since Safety(checking_policy::on_release()) == strong, we need to check its purity. Indeed, it is required to be pure, so we set safety to min(strong, safety), which is strong. We're now in state <strong,true,0,0>.

Next, we check ownership_policy:: on_release(). This may also throw, but it is also strong and pure, just like checking_ policy::on_release(). Thus, the state remains unchanged. Because get_impl_ref() has the same exception properties as get_impl(), we can skip over it, since it doesn't change the state (it's the best type of operation money can buy: pure nothrow).

Here's where things get tricky. If we only had one assignment, we would only need to require stored_type::operator=() to be strong. That's because the remaining operations are nothrow. However, since we have two assignments, the operator needs to be nothrow. Note that we ban the two consecutive impure strong operations not so that we can get the strong guarantee, but so that we can get the basic guarantee! If line 4 were to succeed but line 5 threw an exception, both p and *this would own the resource after the call, which would violate an invariant of smart_ptr that requires that either the smart pointers or an external pointer own the resource, but not both.

Since the assignment is impure, we need to change the state to <strong,impure,0,0>. The second assignment won't change this state. Next, we note that default_value() is required to be nothrow and pure, so we can skip over it, the call to get_impl_ ref(), and the assignment. Finally, we check ownership_policy::reset(), see that it is impure nothrow, and arrive at the end of our function. Our state did not change since the first assignment, so when all the dust settles, we end up with <strong,impure,0,0>. Thus, we can conclude that smart_ptr:: release() is an impure function that provides the strong guarantee.

To double-check our work, we can see if it matches the strong format given in the previous article [3]:

<b>pure*   strong?   nothrow* </b></p>

where "*" means "zero or many" (the Kleene star known from regular expressions) and "?" means "zero or one instances." David Abrahams helped us clarify that "pure" in this formulation means a "pure operation," which can be a pure statement, a call to a pure function, a call to an impure function that only modifies local automatic state, or an impure statement which only modifies local automatic state. This is to avoid confusion with the notion of "pure function," which already has a well-established meaning. We call the property of only modifying local automatic data "operational purity." Now, get_impl(), checking_policy::on_release(), and ownership_policy::on_release() are all pure. Furthermore, get_impl_ref(), stored_ type::operator=(), storage_policy::default_ value(), and ownership_policy::reset() are all nothrow. So our function indeed has the form given — and so should yours.

This algorithm can be useful in two directions. Not only does it give you the safety guarantee of the analyzed function, it can also help you decide what guarantees you require of the component operations. In the case of smart_ptr, it helps us impose minimum guarantees on various policy functions. Also note that some of the constraints were not derived so as to obtain the strong guarantee, but merely to get the basic guarantee, and we got the strong guarantee as a bonus. For instance, if we were to allow storage_ policy::default_ value() to only provide the strong guarantee, we would break the invariant mentioned before in the discussion of stored_type:: operator=(). If we were to allow ownership_ policy::reset() to only give the strong guarantee, the ownership policy could get out of sync with the rest of smart_ptr, breaking another invariant.

Conclusion

This month, we took a close look at the behavior of smart_ptr's constructor in the presence of exceptions thrown by its policies. During initialization of an object that inherits or contains several others, we encounter a "who's holding the hot potato" issue: If a subobject throws an exception, things are not under the control of the big object. The problem lies beyond policies and pertains to any object that needs to manage several resources (remember the A and its two Bs?). We described two idioms for handling that. One uses a constructor try block and an extra concealed argument to the constructor. The other defines a little resource_manager class that glues together critical resources. The amended smart_ptr implementation behaves properly when its policies throw exceptions (or so we think). In the process of hacking at smart_ptr, we learned a lot of good lessons that we hope we passed to you, too. Now we have more structure, more idioms, terminology, and an informal algorithm to assess the exception safety of a function. In the next installment, we're ready to give smart_ptr a test drive and to compare its speed and mileage with other consecrated smart pointers.

References

[1] David Abrahams. Exception Safety in Stlport, 1997. http://www.stlport.org/doc/exception_safety.html.

[2] Andrei Alexandrescu and David B. Held. "Generic<programming>: Smart Pointers Reloaded." C/C++ Users Journal, October 2003. http://moderncppdesign.com/publications/cuj-10-2003.html.

[3] Andrei Alexandrescu and David B. Held. "Generic<programming>: Exception Safety Analysis." C/C++ Users Journal, December 2003. http://moderncppdesign.com/publications/cuj-12-2003.html.

[4] Herb Sutter. "Guru of the Week 82: Exception Safety and Exception Specifications: Are They Worth It?" http://www.gotw.ca/gotw/082.htm.

[5] Herb Sutter. "Guru of the Week 66: Constructor Failures" http://www.gotw.ca/gotw/066.htm.