Sutter’s Mill

#include <memory>

class X {
    // make all ctors private
    X();
    X(const X&);
    // and any other ctors go here

public:
    // Factory function (or it could be a nonmember friend)
    static auto make( /*…*/ ) { return std::unique_ptr<X>(new X( /*…*/ )); }

    // the usual public member functions go here
};

int main()
{
    X x;                  // error 
    auto x2 = X::make();  // ok
}

Posted in C++ | 9 Comments

9 Responses

1. on 2014-06-17 at 6:22 am Victor

   My idea is a wrapper around. Is there any issues?

   template <typename Wrapped> class HeapOnly 
   {
   public:
   	typedef std::unique_ptr<Wrapped> TPtr;
   	typedef const std::unique_ptr<Wrapped> TConstPtr;
   	
   private:
       TPtr m_wrapped;
   
   public:
   
       operator TPtr&      ()       { return m_wrapped; }
       operator TConstPtr& () const { return m_wrapped; }
   
       HeapOnly(/* sorry, but I'm unfamiliar with variable templates so far...*/) 
           : m_wrapped( std::make_unique<Wrapped>(/*...*/) )
       {}
   };
   
   class A {
   private:
       A() {} // private ctors
   
   	// ...
   public:
       // ... others 
       friend class HeapOnly<A>;
   };
   
   void f()
   {
        HeapOnly<A> compilationOk;
        A compilationError;
   }
   

   
   
2. on 2014-06-04 at 7:43 pm Teddy

   @Grout: Deriving from enable_shared_from_this doesn’t actually block compilation of code that instantiates the object on the stack. Nor does it block compilation of new Foo(). I have found the PrivateConstructorTag to be the best way to ensure that a class that inherits from enable_shared_from_this is only constructed with make_shared().

   
   
3. on 2014-05-09 at 2:51 pm Grout

   If

   make_shared()

   is the plan anyway, then deriving from

   std::enable_shared_from_this<>

   may be adequate. No?

   
   
4. on 2014-05-04 at 10:55 pm Norbert Riedlin

   Hi. Does std::make_unique have the same problems with the private constructor pattern as std::make_sharedcode> have? I.e. that it is not portably possible to make std::make_shared a friend of X in the example. What is the preferred way to solve this problem? Is the use of the PrivateConstructorTag the only way?

   
   
5. on 2014-05-04 at 10:41 am Zenju

   Correction:

   	X(..., PrivateConstructionTag);
   public:
   

   should be

   public:
   	X(..., PrivateConstructionTag);
   

   
   
6. on 2014-05-04 at 10:31 am Zenju

   @Good point, thanks. Fixed.

   But this also gives up on the perf and memory layout advantages of std::make_shared… In library code this could be premature pessimisation. What about:

   class X
   {
   //make all ctors private

   struct PrivateConstructionTag {};

   public:
   static auto make( /*…*/ ) { return std::make_shared( /*…*/ PrivateConstructionTag()); }
   };

   I’m using this pattern in my library code. Is this the best solution?

   
   
7. on 2014-05-04 at 4:31 am Herb Sutter

   @mttpd: The protected destructor solution also works, but it’s a C++98 idiom that’s now inferior because it requires using a custom ‘deleter’ function that is possible, but less natural and idiomatic in modern C++, to use together with unique_ptr and shared_ptr.

   @Petter: Good point, thanks. Fixed.

   
   
8. on 2014-05-04 at 3:46 am Petter

   But std::make_unique also requires access to the constructor, right? X::make could create the unique_ptr manually instead.

   
   
9. on 2014-05-04 at 2:15 am mttpd

   How about the protected destructor solution?
   For instance, as suggested here:
   http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Requiring_or_Prohibiting_Heap-based_Objects

   
   

Comments are closed.