Dave Abrahams wrote:
Not so for Boost 1.29.0: you didn't have to pay for a separate count object.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.
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 a shame. There's no reason we can't "go the policy based route" asI 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.
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 ;-)
David Bradley
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
