"John Maddock" <john@johnmaddock.co.uk> writes:
Things like auto_ptr aside, you'd need to templatize the once_flag on the return type then, since the first time value needs to be stored somewhere. Is this worth the hassle?
I think yes.
How about the attached version? The result is stored on the heap, which adds some performance cost, but the once_flag itself doesn't need templating. I haven't yet adjusted it to avoid this heap allocation for void functions.
It does mean that the initializer is now an aggregate initializer rather than a constant, as for my original Semaphore-based version.
Interesting, but don't you end up with the classic singleton problem of "when do I delete this object?", doesn't this implementation risk deleting the object before the last call to the function? There may be workarounds, but I'm not convinced at the moment that they are worth the hassle, are we convinced that having a return value is really that important?
Hmm. This implementation deletes the return value when the once_flag is destroyed, relying on the compiler to do this at an appropriate time. Of course, if the once_flag is a static, and the compiler chooses a poor order of static destruction, such that a destructor called later needs the once_flag, then you have a problem. The alternative is to not destroy the return value, which doesn't strike me as a good option. Maybe this *is* too much hassle.
I also have a slightly reworked version of call_once for you to consider, it's basically the same as your last version, but does away with the need to use stringstreams when creating the mutex name - this cuts down on the memory allocation calls, which should be a big win the first time through.
Thanks. I had meant to do something like this, but figured I'd leave it for later. Anthony -- Anthony Williams Software Developer