Boost logo

Boost :

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-08 11:29:35

--- David Abrahams <dave_at_[hidden]> wrote:
> You mean like prepending char? I missed that, but anyway, it changes
> the invariant of the type you get back. At that point, it might not
> contain any of the types you wanted. It almost becomes equivalent to
> a design Eric rejected, where the variant can be empty.

I agree.

Another potential problem with variant design
is unpredictable execution times for seemingly
equivalent variants.
I have already told Eric about it.
Consider the following code.

 struct my_type
    my_type() {}
    my_type( const my_type& l )
 typedef variant< int, my_type > vt1;
 typedef variant< my_type, int > vt2;
 my_type m;
 vt1 v1;
 vt2 v2;
for( i = 0; i < 10000000; ++i )
   v1 = m;

for( i = 0; i < 10000000; ++i )
   v2 = m;

If the user is to profile the code,
she will be really confused about why section #1
is exectuted much faster than section #2.

In generic context (when variant first types are generic),
the executions time of a program with variants
is totally unpredictable.

Eric mentioned that the heap backup
doesn't give a strong exception safety anyway.
Why bother then?
I would prefer to get rid of the heap backing
and inconsistent exception safety all together.
Just let the user to handle the exception
safety the way she likes,
variant is a too basic data type for that.


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

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