Frank Mori Hess wrote:
On Thursday 09 July 2009, Andrey Semashev wrote:
Why not having monitor_ptr< T > contain the shared_ptr and implement operator-> the way you described?
Yes, that is in fact what I did:
http://www.comedi.org/projects/libpoet/boostbook/doc/boostbook/html/poet/mon...
However, it seems like more work to have to provide a full shared_ptr interface, than to implement a plain pointer interface.
You don't have to reimplement shared_ptr interface, unless you really need it. And that interface isn't that sophisticated, anyway.
And perhaps more significantly, a monitor_ptr is a completely different type than a shared_ptr. So, for example, a monitor_ptr can't be passed to a function that expects a shared_ptr as an argument.
Types shared_ptr<monitor<T*> >, shared_ptr<T*> and shared_ptr<T> are not compatible either, so you don't win here anything.
Also, if there are other applications for pointer wrapper classes, they could be mixed an matched in any combination by the end user in this scheme, like
shared_ptr<monitor<pointer_wrapper<T*> > >
Maybe, for example, a pointer wrapper class might enforce that the wrapped pointer may never be NULL, to implement a shared_ptr that acts something like a "smart reference".
IMHO, one of the remarkable features of shared_ptr is its simplicity. All additional features that you describe, while being useful, are out of scope of this simple tool. I agree that some more elaborate policy-driven smart pointer would be useful to implement those things. It just isn't related to shared_ptr in any way. IIRC, Andrei Alexandrescu tried to develop such a pointer, I'm not sure how successful he was.