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-----
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:
monitor_unique_lock<monitor_ptr<int> > lock(mp); //locks mutex
lock->f();// calls X::f
}// 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)
-----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