Boost logo

Boost :

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2005-09-05 17:07:14


"John Maddock" <john_at_[hidden]> 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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk