bringiton> i was thinking about doing allocation in the constructor, but this bringiton> opens too much confusion because it would be unclear via the interface bringiton> whether the default contructor would 1. allocate a null/empty bringiton> shared_ptr, or 2. allocate a default object. ie If you have null wrapper object, you have to have a way to reset it and a way to check for nullness. Also, unless null objects will be used often enough, it might be better to move creation of null wrapper into a static function (and leave constructors to do the resets) Ptr<Test> p(Ptr<Test>::Null()); Have a private constructor that will accept pointer to managed class (just for signature, you will never need it normally anyway), and call it with NULL. template<class T> class Ptr { public: Prt() { m_ptr.reset(new T()); } static Ptr<T> Null() { return Ptr<T>((T*)NULL); } private: shared_ptr<T> m_ptr; Ptr(T* t) { } }; bringiton> Ptr<Test> p(1, 'a', "hello"); // OK, object created bringiton> Ptr<Test> p2; // ??? unclear if default object allocated or null pointer You have to document it once :). And having an explicit way of creating null wrappers is pretty self explanatory. bringiton> i'm hoping the compiler would be able to optimise the above. ie use bringiton> copy constructor instead of default constructor + operator=(). maybe bringiton> even realise that only 1 object needs to be created. **but i dont know bringiton> much about this area Yep, it will be done through copy constructor.