Zitat von Andrey Semashev <andrey.semashev@gmail.com>:
a better implementation of the existing thread_specific_ptr interface can be almost as efficient as static_thread_specific_ptr. there is one additional indirection (two in the prototype implementation), but it is just as efficient as thread_local otherwise.
How do you work around the problem with delay loaded dlls?
I don't. I suppose platforms that have that problem can be supported by hiding the TLS vector behind a function call, or if the platform doesn't support global TLS but supports TLS that is local to the DLL the pointer to the TLS vector could be obtained under a mutex lock for each module. note that this implementation only uses one TLS variable. if it can't be supported you'd have to fall back to TlsAlloc etc. I think this rather obscure use case should not punish most use cases. Vicente has performed some performance tests of Boost.Transact (that uses static_thread_specific_ptr) on different platforms, some supporting TLS, some don't. IIRC it is pretty much unusable on platforms that don't.