Anthony Williams wrote:
Roland Schwarz <roland.schwarz@chello.at> writes:
But I think your intent is: since we make the object appear like they are static, they should behave similar to real static objects. Correct?
Yes, that's what I meant.
Umm, than as I would say in germanish "we get into devils kitchen". 1) We will need to assume that the call to atexit is thread safe 2) We will need to be able to have the compiler somehow generate a distinct function for every separate instance. And this only when the declaration has been done with the static keyword in front, else we would need to destroy when the object gets out of focus. And even if we could manage this, the whole concept of destruction order of static objects seems void in the presence of threads anyways. You can see this e.g. from the fact that local static is an illegal construct when seen from the perspective of the standard. Even when protected by a mutex the destruction order is arbitrary anyways, so I tend to say that even such a usage is very problematic. (Put aside the question whether atexit calls are thread safe.) So as I see it the only way out is to treat them as as heap objects with dynamic lifetime (as what they really are) and their own rules, of existence, while giving them certain properties that make them usable as if they were static. Call them lazy_static<> perhaps, or to make their dynamic nature more visible to the user: lazy_ptr<> ? Roland