Howard Hinnant wrote:
thread_specific_ptr<T> is the thread local data storage mechanism of the excellent (thanks William!) boost threads library. thread_specific_ptr<T> isn't capable of supporting custom deleters for good reason.
Actually, the version of thread_specific_ptr<T> that is currently in CVS (recently moved from the thread_dev branch) does support custom cleanup functions.
The deleter function must be a real function (not a functor) so as to work well with various OS level threading api's (like Posix threads). So the pointer passed into a thread_specific_ptr<T> (via reset) must be free-able with delete.
thread_specific_ptr<T> could offer a custom deleter constrained to be a function pointer instead of a more general deleter policy (functor), but that seems like it would be of limited functionality and frankly just not much fun in a C++ environment.
It does have the limitation of using a real function pointer that takes a T* and returns nothing.
However, there is one case where another deleter policy is common enough to warrant special attention: delete [].
So I suggest a partial specialization for thread_specific_ptr:
I suppose there could still be a partial specialization such as you describe that supplies a default deleter that calls delete[] if the user doesn't supply a custom deleter. [snip code] Mike