[boost] Re: boost::execution_monitor impl under windows

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-08 14:21:43

"E. Gladyshev" <egladysh_at_[hidden]> writes:

> --- David Abrahams <dave_at_[hidden]> wrote:
>
> [...]
>> Let me try again: 
>> 
>> - the variant design has a nice invariant that it contains one of the
>>   types that were passed as template arguments
>> 
>> - if a library takes a user's list at face value, the library
>>   designer gets the benefit of that invariant.
>> 
>> - if a library designer wants the optimization in the cases where
>>   it's possible, she either has to:
>> 
>>   - prepend empty_type to the list in order to ensure it, and give up
>>     on the nice invariant
>> 
>>   - implement a moderately-complex type sequence reordering algorithm,
>>     which surely costs far more in compilation resources than the
>>     simple search that would be implemented by the library to provide
>>     the optimization whenver possible.
>> 
>> IOW, we make the library designer choose between safety and efficiency
>> at compile-time just to get runtime efficiency.
>
> I would add to what David just said.
>
> According to Eric, the current variant implementation doesn't 
> provide a *strong* exception safety anyway.
> So I would argue that the *weak* safety is not really usefull.

I don't know what *weak* means, but if you mean the basic guarantee
isn't useful, I have to disagree.  It's exceedingly useful, and is
provided by most of the standard library.  An implementation should
almost never compromise efficiency to get the strong guarantee, since
that typically can be added by a copy/swap layer over the top of the
operation when neccessary.

> I would also argue that in 99.9% cases given a choice 
> between the optimization and weak exception safety, 
> the user will choose the optimization.
> So 99.9% of all users will need to add the empty type
> to the begining of all their variants.
>
> It seems that the only justification
> was O(N) vs. O(2N) compile-time improvement that
> as David just pointed out, is not really an 
> improvement at all.

Right, either one is still O(N).

> My vote is to remove the *weak* exception safety

There was a brief period when I referred to the basic guarantee as
the "weak guarantee", but I quickly killed that term because it is too
pejorative for a guarantee that's perfectly good and quite useful.
Please don't revive it unless you're giving it a different meaning!
Incidentally, I now wish I'd chosen a different name for the strong
guarantee, because it's too complimentary a term for a guarantee that
is by no means a silver bullet ;->

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com