Re: [boost] Re: Re: Smart pointers: One more implementation +question

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
was
> > 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
their project.

> 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
objects ;-)

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com