Boost logo

Boost :

From: David Bradley (dbradley_at_[hidden])
Date: 2003-02-06 08:10:27

Dave Abrahams wrote:

>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.
That's good to know. This discussion has brought up some issues that I
probably need to raise about what's being done in Mozilla as well. I
have some concerns, because creating smart pointers can appear to be
deceptively simple.

>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 ;-)
I wonder if there may have been issues or holes in the policy based
pointer implementation that I worked on years ago that we didn't
encounter or think about at the time. I'm trying to figure out where the
wasted space would be in a policy based design. Any overhead at the for
the pointer is something to seriously consider and weigh.

David Bradley

Boost list run by bdawes at, gregod at, cpdaniel at, john at