Boost logo

Boost :

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-08 13:50:46

--- 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 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.

My vote is to remove the *weak* exception safety
from variant all together. Come on guys, variant
should be imlemented as a very basic type with
a clear and intuitive behaviour.
Don't try to be too smart with it. :)


Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

Boost list run by bdawes at, gregod at, cpdaniel at, john at