The purpose of the memory management smart pointer concept is to hold a C++ built-in pointer and to manage its memory ownership. A smart pointer is a an example of the "resource acquisition is initialization" technique described by Stroustrup in "The C++ Programming Language" [14.4.1].
In a larger sense, smart pointers are not limited to memory management. Other roles they can play include checking, locking, loading, and navigation. Most iterators in the standard library are examples of smart pointers even though they don't have strong ownership semantics. The feature model presented here focuses only on memory management design features.
For more information about feature diagrams, see www.boost.org/more/feature_model_diagrams.htm.
To ease implementation, array is not allowed with attached-reference-count, but there are no other constraints.
This feature diagram generates over 100 valid configurations. Most, if not all, of those configurations are actually useful in practical applications.
The most fundamental feature of a memory management smart pointer is how the ownership of the pointed-to memory is managed.
- unowned: By supplying a "do nothing" user-deletion function, ownership is effectively not exercised.
- scoped: The pointed-to memory is deleted when the smart pointer is destroyed.
- transferable: The pointed-to memory is deleted when the smart pointer is destroyed. Ownership may also be transferred to another smart pointer. In other words, the std::auto_ptr<> semantics.
- shared: Ownership of the pointed-to memory is shared between multiple smart pointers; deletion occurs when the last sharing pointer is destroyed. Does not work in the presence of cyclic references.
- detached-reference-count: Direct (smart pointer contains pointers to object and to count) feature only currently supported. Indirect (smart pointer contains pointer to struct containing pointer to object and the count.) feature may be supported in the future.
- attached-reference-count: The pointed-to object must contain an invasive reference counter. (A non-invasive attached-reference-count (count_bdy like) or linked-pointer (linked_ptr like) features may be supported in future revisions.)
- collected: Ownership of the pointed-to memory is shared between multiple smart pointers; deletion occurs at some time after the last sharing pointer is destroyed. Does work in the presence of cyclic references. AKA garbage collection.
- implicit-allocation: A C++ new-expression [ISO 5.3.4] will be done automatically by the smart pointer constructor. Safer than user-allocation.
- user-allocation: The user must allocate and supply a pointer to the pointed-to memory. Although slightly more flexible, this approach is more error prone since errors such as passing in a pointer not allocated by a new-expression, or a pointer already owned by another smart pointer are possible.
- implicit-deletion: Deletion will be via a C++ delete-expression.
- user-deletion: Deletion will be via a user supplied deletion function.
C++ language rules [ISO 5.3.5] require that the type being deleted by a delete-expression be either a complete type or have a trivial destructor [ISO 12.4].
- complete-or-trivial-dtor: The type is complete or the destructor is trivial.
- incomplete-with-non-trivial-dtor: The type is incomplete and the destructor is non-trivial. A user-deletion function defined in a translation context when the type is complete must be supplied.
- no-implicit-conversion: operator T* is not defined for the pointed-to type T. This ensures that an unwanted conversion will never occur. It is thus the slightly safer choice.
- implicit-conversion: operator T* is defined for the pointed-to type T. This mimics built-in pointers, and improves readability in programs where many function arguments require raw pointers.
Portions of this discussion are based on boost mailing list postings by Kevlin Henney.
The format for this page was patterned after Jeremy Siek's Mutex Feature Diagram page.
Revised 13 Oct 2000
© Copyright Beman Dawes, 2000