From: John Maddock (john_at_[hidden])
Date: 2005-09-08 04:49:18
>>> If we store the return value along with the once_flag, then we really
>>> to destroy it properly, when the once_flag is destroyed. If a once_flag
>>> static storage duration, and has a non-trivial destructor that does
>>> cleanup, then we have a classic singleton cleanup problem, as John
>>> pointed out --- the order of static destruction can now be important.
>> You mean an extra non-POD version? That's not your problem... as long
>> as you provide a POD version + call_once_reset/destroy().
> So, you're suggesting that we store the result with the once_flag, and
> leave it up to users to schedule a call to call_once_reset, to ensure the
> result gets cleared up?
> I'd still like to know how the user can safely schedule the call to
> call_once_reset, so it doesn't cause problems. I suppose there's an
> element to
> which it doesn't really matter; the result will just be reinitialized if
> there's a subsequent call_once.
> I don't like leaving things as "not my problem", unless I can see that
> is a safe solution.
Me neither, and I still don't see what having a return value really gains us
in this case (I would much rather be able to pass parameters to the
call_once procedure, but that's a whole other ball game).
If a return value is truly required, then we could use aligned_storage to
provide raw storage for the return value and construct the object on first
call to the one procedure, but that still doesn't solve the destruction
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk