"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? > 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. Dave _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
