From: Randy Bowen (rbowen_at_[hidden])
Date: 2003-09-24 10:56:09
> I noticed that the design could be optimized towards
> flexibility and better source code maintainance by
> parametrizing the template with another type to decouple the
> deletion behavior from the smart pointer template itself.
Isn't this functionality already there? The following is from the
template<class Y, class D> shared_ptr(Y * p, D d);
Requirements: p must be convertible to T *. D must be CopyConstructible.
The copy constructor and destructor of D must not throw. The expression
d(p) must be well-formed, must not invoke undefined behavior, and must
not throw exceptions.
Effects: Constructs a shared_ptr that owns the pointer p and the deleter
Postconditions: use_count() == 1 && get() == p.
Throws: std::bad_alloc or an implementation-defined exception when a
resource other than memory could not be obtained.
Exception safety: If an exception is thrown, d(p) is called.
Notes: When the the time comes to delete the object pointed to by p, the
stored copy of d is invoked with the stored copy of p as an argument.
[Custom deallocators allow a factory function returning a shared_ptr to
insulate the user from its memory allocation strategy. Since the
deallocator is not part of the type, changing the allocation strategy
does not break source or binary compatibility, and does not require a
client recompilation. For example, a "no-op" deallocator is useful when
returning a shared_ptr to a statically allocated object, and other
variations allow a shared_ptr to be used as a wrapper for another smart
pointer, easing interoperability.
The support for custom deallocators does not impose significant
overhead. Other shared_ptr features still require a deallocator to be
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk