On Wednesday, February 05, 2003 11:14 AM [GMT+1=CET], David B. Held <[EMAIL PROTECTED]> 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? Lots of ways. For example, the smart pointer objects could be bigger than neccessary. > > 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. Type generators are overkill, since unlike with iterator adaptors there's no need to preserve type identity. Normal inheritance will work just fine. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
