shared_ptr improvement proposal by T. Lovset --- note: Parts of this may be long-winded and possible obvious to some of you, but I feel it is needed to support the arguments. Let me know what you think. --- I propose a modification to the smart pointer classes. In my opinion, this modification improves the current smart pointer usage in several respects, although it is not completely backward compatible. However, that is also the main purpose of the modification, because as we know, the explicit constructors that take a raw pointer is dangerous in numerous ways. As an illustration, I show a realistic example that violates the smart pointer preconditions in a subtle (and dangerous) manner. As a background, some quotes from the boost "Proposal to Add General Purpose Smart Pointers to the Library Technical Report" (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1450.html): (1)
A common concern, dating back to [Colvin94], is that it is very easy to violate the preconditions of smart pointer operations. This proposal attempts to systematically eliminate undefined behavior possibilities as long as the user is manipulating already valid shared_ptr (and weak_ptr) instances, but using the pointer constructor correctly is still up to the user.
- Widespread existing practice strongly favors the unprotected but powerful
And: pointer constructor
approach.
(2)
A. General Principles 1. "As Close to Raw Pointers as Possible, but no Closer"
For auto_ptr and shared_ptr, we are familiar with the form: shared_ptr<Widget> smartWidgetPtr( new Widget(a, b) ); The constructor is made "explicit" in order to avoid implicit and unintentional construction of smart pointers, e.g.: void f( shared_ptr<Widget> const & wp ); would without explicit constructors accept f(rawWidgetPtr) with disastrous results. Still, as mentioned, "explicit" does not make up for all misuses. For example, an inexperienced user could try to call f(shared_ptr<Widget> (rawWidgetPtr)) to make it compile. Fortunately, this is quite easy to spot as an error, and therefore "explicit" does it's mission here. But a much more common and subtle problem may arise when converting from raw pointers to smart pointers: class WidgetUtil { public: WidgetUtil(Widget* wp); private: Widget* m_wp; }; WidgetUtil::WidgetUtil(Widget* wp) : m_wp(wp) { ... } Now converting to shared_ptr: class WidgetUtil { public: WidgetUtil(Widget* wp); private: shared_ptr<Widget> m_wp; }; The unmodified constructor still compiles, but the precondition for m_wp is violated. One must therefore pay close attention to the constructors to make sure that they do not take raw pointer as arguments, which initializes smart pointers. In the case of a big class with a mixture of both smart and raw pointer members, the principle of "using the pointer constructor correctly is still up to the user", lays an unacceptable heavy burden upon the user (in my opinion) - especially when it is possible to avoid this problem. Before I move on to the proposal, I'll address another drawback with the current smart pointer implementations: implicit ctor-initialization and assignment to NULL (which is possible with raw pointers) is not supported. This would make things much easier when converting back and forth between smart and raw pointers. It also breaks the principle of "As Close to Raw Pointers as Possible, but no Closer". My proposal makes this possible, and thus making the usage closer to that of raw pointers, without introducing any side effects. [As a side note, Joe Guttman pointed out to me that with the proposed nullptr and nullptr_t, it will be easy to add these features to the current implementations of smart pointers. However, my proposal does not rely on nullptr.] The Proposal ============ Note that this proposal would be beneficial to most smart pointer implementation, including shared_ptr and auto_ptr. Unfortunately, auto_ptr is already in the standard, so it can't be touched. I propose this usage (for shared_ptr): shared_ptr<Widget> wp1 = NULL; shared_ptr<Widget> wp2 = rawptr(new Widget(a, b)); wp1 = rawptr( new Widget(a, b) ); wp2 = NULL; Current shared_ptr usage: shared_ptr<Widget> wp1( NULL ); shared_ptr<Widget> wp2( new Widget(a, b) ); wp1.reset( new Widget(a, b) ); wp2.reset(); Discussion: 1. As wp1 and wp2 should be raw pointer "look alikes", the proposed usage is more intuitive than the current usage, in my opinion, and allows to assign NULL without side-effects. 2. As noted by others [e.g. Andrei Alexandrescu], member functions in smart pointers should be avoided if possible. The reset() function makes it hard to switch between raw and smart pointers, and also allows mix-ups: wp1.reset(), (*wp1).reset(), wp1->reset(). 3. The rawptr() function makes initialization and assignment explicit using an alternative and better syntax, IMO. E.g., you can verify that every shared_ptr owns a valid raw pointer by investigating instances of "rawptr(" in the code. Typically, you want to see: rawptr(new SomeClass(..)). To do this is not easy with the current implementation. You have to search for: a) "shared_ptr<" stack variable constructions of which takes raw pointers as arguments. b) ".reset(" for re-assigning a new raw pointer. Unfortunately reset() is a commonly used name. c) shared_ptr's in class member initiation lists, as mentioned in the example presented. 4. Most importantly, all raw pointers that are assigned to smart pointers must go through the rawptr() function (or rawptr_t<T> type), always making it "explicit". The problem in the example presented earlier, is therefore eliminated. 5. This proposal introduces no additional overhead, as long as the compiler really inline the rawptr() function (the operator new call is dominant by an order of magnitude in any case). 6. The only obvious problem I see, is the backward compability issue, although it still support the "unprotected but powerful pointer constructor approach", with a slightly different syntax. Implementation for shared_ptr ============================= rawptr.hpp (new file): --------------------- namespace boost { template <class T> class rawptr_t { public: explicit rawptr_t(T * p) : px(p) {} T* get() const { return px; } private: rawptr_t& operator=(const rawptr_t&); T* px; }; template <class T> inline rawptr_t<T> rawptr(T * p) { return rawptr_t<T>(p); } } shared_ptr.hpp (diff from boost 1.31.0): ---------------------------------------- *************** *** 109,114 **** --- 123,129 ---- // Borland 5.5.1 specific workaround typedef shared_ptr<T> this_type; + struct null_tag {}; public: *************** *** 117,130 **** typedef T * pointer; typedef typename detail::shared_ptr_traits<T>::reference reference; ! shared_ptr(): px(0), pn() // never throws in 1.30+ { } template<class Y> ! explicit shared_ptr(Y * p): px(p), pn(p, checked_deleter<Y>()) // Y must be complete { ! detail::sp_enable_shared_from_this(p, p, pn); } // --- 132,145 ---- typedef T * pointer; typedef typename detail::shared_ptr_traits<T>::reference reference; ! shared_ptr(null_tag* = NULL): px(0), pn() // never throws in 1.30+ { } template<class Y> ! shared_ptr(rawptr_t<Y> const & w): px(w.get()), pn(w.get(), checked_deleter<Y>()) // Y must be complete { ! detail::sp_enable_shared_from_this(w.get(), w.get(), pn); } // *************** *** 226,231 **** --- 241,258 ---- } #endif + shared_ptr & operator=(null_tag *) + { + reset(); + return *this; + } + + template<class Y> + shared_ptr & operator=(rawptr_t<Y> const & w) + { + this_type(w).swap(*this); + return *this; + } void reset() // never throws in 1.30+ { *************** *** 235,241 **** template<class Y> void reset(Y * p) // Y must be complete { BOOST_ASSERT(p == 0 || p != px); // catch self-reset errors ! this_type(p).swap(*this); } template<class Y, class D> void reset(Y * p, D d) --- 262,268 ---- template<class Y> void reset(Y * p) // Y must be complete { BOOST_ASSERT(p == 0 || p != px); // catch self-reset errors ! this_type(rawptr(p)).swap(*this); } template<class Y, class D> void reset(Y * p, D d) ------------------------------------------------------------ Få din egen @start.no-adresse gratis på http://www.start.no/