From: Dave Abrahams (dave_at_[hidden])
Date: 2003-02-05 22:20:09
On Wednesday, February 05, 2003 9:18 PM [GMT+1=CET],
David Bradley <dbradley_at_[hidden]> wrote:
> Dave Abrahams wrote:
> > Actually, shared_ptr magically deals with this problem by instantiating
> > the deleter at the point where it takes ownership of its resource. As
> > long as that's on the same side of the DLL boundary where the resource
> > allocated, you're golden.
> That's something I missed in skimming the implementation, it looked as
> though it was done in the header file. I guess I still find myself on
> the side of seeing the benefits of policy based implementation, and
> finding it hard to see the how it makes things more complex, other than
> for people trying to create new smart pointers implementations, which I
> would argue is difficult in itself and prone to more error than creating
> the necessary traits class for a policy based system.
> While working on Mozilla one of the cons against using Boost's shared
> pointer was that it incurred additional storage for the counter, and the
> engineers working on Mozilla wanted an intrusive implementation where
> the counter was stored with the object. It looks like the current
> implementation there is no way other than to create yet another smart
> pointer class to do this.
Not so for Boost 1.29.0: you didn't have to pay for a separate count object.
In the current CVS, you do.
However, using BOOST_SP_USE_QUICK_ALLOCATOR, having a separate count object
doesn't have to incur any "extra" storage per object. If the mozilla
designers want less storage overhead than that, they'd have to give up
features of boost::smart_ptr that would seem to be important for a project
like that: weak references, correct interoperability across DLL boundaries,
safe upcasting of pointers to objects without virtual destructors, to name a
few. None of that is to say that they didn't make the right choice for
> Had Boost gone the policy based route, Mozilla
> would have been able to use such a smart pointer, as it is, Mozilla is
> reinventing the wheel instead of using Boost.
That's a shame. There's no reason we can't "go the policy based route" as
well, provided we can get the issues worked out. As I suggested earlier,
and as evidenced by the choices of the Mozilla designers, people who want
custom smart pointers are usually interested in efficiency. So far, we
don't have a policy-based design which doesn't incur wasted space for *each
pointer* on common compilers. That's a lot more serious than incurring
overhead once, for a separate count object, in a lot of applications, since
the whole point of a "shared" pointer is that there are more pointers than
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk