Zitat von Peter Dimov <pdimov@pdimov.com>:
Stefan's idea was to reuse slots in the vector. This would avoid reallocation when keys are created and destroyed at the same rate. Unfortunately, on second thought, this isn't as straightforward as it seemed; threads could still hold non-NULL pointers when the key is destroyed.
pthread_key_delete simply discards these non-NULL pointers without cleaning them up; the current implementation performs proper cleanup when the threads end.
so the current implementation destroys the thread specific objects on thread exit even though the thread specific pointer it belonged to was destroyed before? I guess this was the reason to introduce a "key" in the first place? a similar behaviour could be implemented using the vector-technique. the key would have to be stored in the vector at the allocated index along with the pointer so thread_specific_ptr::get() can decide if the pointer is left-over from a previous thread_specific_ptr or an actual pointer belonging to this thread_specific_ptr, and reset() can destroy it.