Boost logo

Boost :

From: David Maisonave (dmaisonave_at_[hidden])
Date: 2006-01-30 16:20:58


"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:<058c01c625d8$b1f98040$6507a8c0_at_pdimov2>...
> David Maisonave wrote:
>
> > Please look at the current smart pointer locking method:
> > http://code.axter.com/smart_ptr.h By using intrusive lock logic, you

> > can lock the pointee, and thereby locking all the shared_ptr
> > objects. Here's the smart pointer destructor:
> > inline ~smart_ptr() throw()
> > {
> > m_ownership_policy.destructor_lock_policy(m_type);
> > CHECKING_POLICY::before_release(m_type);
> > m_ownership_policy.release(m_type, m_clone_fct,
> > m_ownership_policy);
> > CHECKING_POLICY::after_release(m_type);
> > }
> >
> > There's similar logic in constructor and assignment operator. This
> > should work on all three main types of reference policies, to
> > include reference-link.
>
> That's what I thought. But if you have support from the pointee, why
> not
> just use intrusive_ptr? It should be even faster, on all operations,
not
> just init.

Many programs don't need thread logic, and therefore don't require a
synchronize smart pointer.

For those programs that do require a synchronized smart pointer, the
developer may not want to add the extra logic required for
intrusive_ptr, and may only want to make the minimum modifications on
their target object.
In any case, this policy set allows the developer to choose what's the
best combination for their requirement.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk