From: Andrey Semashev (andysem_at_[hidden])
Date: 2008-03-06 14:46:17
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk