Phillip Hellewell wrote:
I can understand an argument against doing it if it is too hard, but why is it so bad to change the spec to allow for an option as long as it is clearly documented that it should not be used if you are using a thread-specific allocator?
Well, the spec is already written, and not by us. http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_key_delete.... Even if we ignore the thread-specific allocation issue, I'm not sure I see how proper destruction can be implemented without imposing synchronization on the normal case. And the whole point of thread-specific storage is to avoid synchronization.
Ok, I think I understand how this could work. There's only one tiny problem though. Although most of my code always creates an Object inside a shared_ptr, it is allowed and there are some places that just create one on the stack and use it, e.g., within a function. Correct me if I am wrong, but this idea can't work unless I forcibly disable the ability to create an Object except via an Object::create() that returns a shared_ptr.
You are right. There is no way to distinguish a stack-allocated Object from another stack-allocated Object created at the same address, so a map keyed by the object address can't work. Your other option may be unique per-object identifiers for use as keys, with ~Object somehow marking the identifier as invalid. But the "invalid identifier" set will soon grow out of hand and I'm not seeing a way to purge it. You could, perhaps, store a shared_ptr to a dummy identifier object and use the corresponding weak_ptr as a key, but I'm not sure that this is worth the trouble (and allocations) if stack use is rare.