From: "Andrei Alexandrescu" <[EMAIL PROTECTED]> > "Peter Dimov" <[EMAIL PROTECTED]> wrote in message > 00b201c2c6da$16c22e70$1d00a8c0@pdimov2">news:00b201c2c6da$16c22e70$1d00a8c0@pdimov2... > > 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. > > I understand that. I also know not all people would need all that.
Absolutely. A single pointer can't answer every problem. But my point was that given the above, custom deleters are essentially free. > > 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. > > I guess I started feeling that way when I've been told that shared_ptr is > everything everyone will ever need, so there's no need for policy-based > smart pointers :o). _I_ never stated that. ;-) > In a language with template typedefs, there would be no complementarity - > shared_ptr will be but one point in the design space allowed by smart_ptr. Again, this depends on the design goals that you have set for smart_ptr. Not stretching smart_ptr to cover shared_ptr may produce a better design. Or it may not. But I don't see shared_ptr as a mandatory point in the design space. The two designs have different basic principles. shared_ptr answers the question "if you had to design a smart pointer that is only parameterized on the value type, and its behavior does not depend on the parameter (i.e. you can state Requires/Postconditions/Throws/Exception Safety independently of the parameter), what would the result be?" smart_ptr<> comes from the opposite end. It is not constrained by a "single type", and uses this fact in its advantage. It is a feature of smart_ptr<> that different pointers have different types. It is a feature of shared_ptr that different pointers have single type. Given a smart_ptr<>, shared_ptr's FAQ would say Q. I need feature X, why doesn't shared_ptr do what I need? A. smart_ptr. By the way, the current typedef template proposal prohibits deduction; this makes it less attractive for creating subpointers. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost