From: Dave Abrahams (dave_at_[hidden])
Date: 2003-02-05 12:13:48
On Wednesday, February 05, 2003 11:14 AM [GMT+1=CET],
David B. Held <dheld_at_[hidden]> 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?
Lots of ways. For example, the smart pointer objects could be bigger than
> > 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk