Boost logo

Boost Users :

From: Evgeniy Zolenko (zolenkoe_at_[hidden])
Date: 2006-07-16 20:39:44


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.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net