On Wednesday, February 05, 2003 9:18 PM [GMT+1=CET], David Bradley <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
