"Sam Partington" <sam.partington@gmail.com> wrote in message news:<546fdb840601310328m7480d265u49afde5a1fd85cfa@mail.gmail.com>...

class A { public: A() : l(m, false) { }

void lock() { l.lock(); } void unlock() { l.unlock(); }

private: mutable boost::mutex m boost::scoped_lock l; };

void intrusive_ptr_lock(A * p) { p->lock(); }; void intrusive_ptr_unlock(A * p) { p->unlock(); }

...

smart_ptr<A, copy_on_write_policy<intrusive_lock_policy> > ptr(new A);

Thats quite a lot of work, though some of the problem with that is probably down to the way boost::mutexes are handled.

I'm still considering adding a lock policy that will only work with reference-count and deep_copy, and that will not require intrusive logic. That would make the usage more generic, but not as efficient as instrusive lock.

std::auto_ptr std::tr1::scoped_ptr std::tr1::shared_ptr boost::cow_ptr ? boost::copy_ptr ?

Should be sufficient for most needs? and everyone one of them is a hell of a lot easier to type than :

boost::smart_ptr<A, boost::copy_on_write_policy<boost::intrusive_lock_policy> >

One thing I really like about the current proposed boost::policy_ptr, is that you can do a typedef on the policy. Example: typedef boost::smart_ptr<boost::ref_linked> MySharedPtrRefLnk; MySharedPtrRefLnk::to<Shape> pShape; So if you don't like all that typing, you can just do a typedef for the type you expect to use in your project. My propose smart_ptr doesn't have such an elegant method as the proposed policy_ptr, but it does have the following: typedef smart_ptr_type<copy_on_write_policy<intrusive_lock_policy> > MyCowSyncSmartPtr; MyCowSyncSmartPtr::to<Shape>::type pShape; I plan to take a look at the policy_ptr, to see how they're going about avoiding the ::type part.