Re: [boost] [smart_ptr] shared_ptr template type

Subject: Re: [boost] [smart_ptr] shared_ptr template type
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2009-07-09 14:42:46

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 09 July 2009, Gottlob Frege wrote:
> On Thursday, July 9, 2009, Frank Mori Hess <frank.hess_at_[hidden]> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > 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.
>
> I don't think lock/unlock on each -> call is typically a good idea.
>  x = p->x;
>  y = p->y;
> That's 2 lock unlock sequences instead of one.  Inefficient and what
> if y changes after you read x?
> It hides the locking too much, potentially leading to abuse and mistakes.

My monitor_ptr also supports scoped locks, so multiple calls can be made into 
the object with one lock/unlock:

http://www.comedi.org/projects/libpoet/boostbook/doc/boostbook/html/poet/monitor_ptr.html

e.g:

monitor_ptr<X> mp;
{
        monitor_unique_lock<monitor_ptr<int> > lock(mp); //locks mutex
        lock->f();// calls X::f
        lock->g();
}// lock destruction unlocks mutex

However, I was hoping to discuss a generalization of shared_ptr more, I mainly 
brought up monitors as a motivating example.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpWOiYACgkQ5vihyNWuA4VUTACg4MtjHL+bPqwLH/1qjp7YzKP1
TgIAn3dm4chUiv2iqgpi+L+gIUlsiMRq
=kKfs
-----END PGP SIGNATURE-----