thread_specific_ptr suggestion

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. 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. 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: template <class T> class thread_specific_ptr<T[]> { public: thread_specific_ptr(); ~thread_specific_ptr(); T* get() const; T& operator[](std::size_t i) const; T* release(); void reset(T* p = 0); private: thread_specific_ptr(const thread_specific_ptr&); thread_specific_ptr& operator=(const thread_specific_ptr&); }; In this case, any pointers owned by thread_specific_ptr<T[]> must be free-able with delete []. thread_specific_ptr<int> value; thread_specific_ptr<int[]> array_value; void foo() { value.reset(new int); array_value.reset(new int [3]); ... } -Howard

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
participants (2)
-
Howard Hinnant
-
Michael Glassford