From: "Andrei Alexandrescu" <[EMAIL PROTECTED]> [...] > > It should be noted that the constructor taking a custom deleter has many > implementation efficiency consequences that are not mentioned in the > Standards proposal nor in the shared_ptr doc. My feeling is that the > documentation at > http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1397.html and at > http://www.boost.org/libs/smart_ptr/shared_ptr.htm is coy about mentioning > that the added constructor requires quite some more overhead under the > covers, including runtime polymorpshim, virtual calls, extra allocations, > all those good things.
The runtime polymorphism/virtual call issue is not exclusively mandated by the two-argument constructor. It is necessary to capture the deallocation information at construction time in order to support incomplete classes, EXE/DLL heap mismatch, and shared_ptr<T>'s ability to call the right destructor regardless of T. There are no extra allocations associated with the two-argument constructor. Many deallocators are empty classes, and it's possible to use the empty base optimization (compressed_pair) so that they add no size overhead. The current implementation doesn't use this optimization, though. > Ah, there's also the compulsive locking on > multithreaded builds (whether the user wants it or not). Yes, this is a very good argument in favor of policy-based smart pointers. You can only go so far given the "one type" constraint. I really don't understand why you consider policy-based smart pointers and the current shared_ptr enemies, when in my opinion they perfectly complement each other. But I've grown tired of asking. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
