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
>> 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
smart_ptr& operator=(const smart_ptr& rhs)
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?
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk