David B. Held wrote:
> "Pavel Vasiliev" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> [...]
>> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
