Re: [boost] Re: unions

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 ) 
    {
       throw;
    }
 };
 
 typedef variant< int, my_type > vt1;
 typedef variant< my_type, int > vt2;
 
 my_type m;
 
 vt1 v1;
 vt2 v2;
 
//#1
for( i = 0; i < 10000000; ++i )
   v1 = m;

//#2
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.

Eugene

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com