Re: [boost] Re: Smart pointers: One more implementation +question

From: Pavel Vasiliev (pavel_at_[hidden])
Date: 2003-02-05 12:21:41

David B. Held wrote:

> "Pavel Vasiliev" <pavel_at_[hidden]> wrote in message
> news:119691015.20030205155314_at_mpen.bas-net.by...
>> [...]
>> Implementing of refc_ptr as a set of policies is also possible, but
>> currently that seems to be overkill, both in unnecessary
>> complexity and performance losses. Though this my opinion may
>> change with time.

> I certainly hope there aren't performance losses!  That's one of the
> main motivations for writing custom policies.  How would there be
> a performance loss with SmartPtr?

Here is the example. Consider the typical implementation of copying
operator=:

smart_ptr& operator=(const smart_ptr& rhs)
{
  smart_ptr(rhs).swap(*this);
  return *this;
}

It is Ok if generality is of primary importance. But let explore
multithreading synchronization: one pair of mutex lock/unlock is
necessary for incrementing in smart_ptr(rhs), another one - for
decrementing during destruction of the temporary. And also swapping of
raw pointers has its cost, if you look into disassembly.

In my implementation of refc_ptr operator= performs
incrementing/decrementing within a single guarded section (since
the only global instance of interl. op. mutex is used for all
cases). So the copying via operator= is about twice faster in my
implementation. I do not know how to achieve this with Loki::SmartPtr.

The true locking/unlocking, not InterlockedIncrement/Decrement() even
if availabe, is necessary to support weak references.

>> Conclusion: IMO, policy-based implementations like
>> Loki::SmartPtr<> and "fixed" ones like boost::shared_ptr<T> or
>> my refc_ptr<T> serve different needs. Do I say something new?
>> Hardly.

> You're right for now, but if we get template aliasing...even so,
> it is possible to emulate almost any pointer with SmartPtr (though
> some are admittedly more difficult than others), and even though
> this requires a non-default policy set, a type generator wrapper
> will usually suffice.

Sorry, David, I only partially understand what you are saying.
Probably this is because I don't have experience in implementing of
policy-based smart pointer myself like you.

Pavel