Peter Dimov wrote:
Andrey Semashev: ....
Agreed. And I for one would personally prefer to see a thread_specific_value instead of thread_specific_ptr in this case.
My favorite spelling is
thread_specific< X > tx;
It can be made to work (I even had implemented it halfway once) but the problematic case is how to handle dynamically loaded (and unloaded) libraries with global/static thread_specific<> variables.
I had done the same thing too (ironically, I used the same spelling as you suggest), but I only needed to store void* sized POD types, so it did not make any dynamic allocations and there were no problems with dlls. In fact, I think such a simple and straightforward tool could be used as a basic building block for a more advanced tool.
The shared_ptr-like deleter functionality is in this case simply spelled
thread_specific< shared_ptr<X> > tpx;
Depending on how the thread_local storage class ends up being specified, we might still need to implement thread_specific at some point.
AFAIR, the C++0x proposal is a new data storage type. Therefore we won't be able to create TLS class members. This is where thread_specific could come into play.