Subject: Re: [boost] [smart_ptr] shared_ptr template type
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2009-07-09 13:54:54
-----BEGIN PGP SIGNED MESSAGE-----
On Thursday 09 July 2009, Andrey Semashev wrote:
> Frank Mori Hess wrote:
> > I wonder if it might be better/possible to have a shared_ptr<T> that
> > didn't assume its corresponding "raw" pointer type was T* but rather T.
> > For example, what is now a shared_ptr<int> would be specified as a
> > shared_ptr<int*>. The motivation would be to allow support for other
> > classes as the "raw" pointer type. For example, I might want to have a
> > shared_ptr<monitor<T*> > where the monitor<T*> has an operator->() which
> > does automatic locking/unlocking of a mutex before/after forwarding the
> > operator->() to the plain T pointer.
> 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:
However, it seems like more work to have to provide a full shared_ptr
interface, than to implement a plain pointer interface. 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.
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".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk