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