Re: [boost] [variant] Maintainer

Subject: Re: [boost] [variant] Maintainer
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-06-27 11:38:59

Le 26/06/15 08:59, Antony Polukhin a écrit :
> 2015-06-26 9:10 GMT+03:00 Vicente J. Botet Escriba <vicente.botet_at_[hidden]
>> :
>> Hi Anthony,
>>
>> I would suggest you to have two separated classes, one the existing one
>> and the other that can be used to experiment and move towards whatever the
>> experimental standard variant would become. Note that the proposal is
>> moving a lot and there is not yet enough consensus on its semantic.
>>
> This seems like an overkill in this particular case.
>
> There's an Eggs.Variant that matches proposal better. Totally rewriting
> Boost.Variant to be close to it seems wrong.
I'm not talking of rewriting anything, but of writing :)
I have a bad experience adding new functionalities in Boost.Thread. Now 
I believe that I should had created a new and separated version instead. 
Boost.Variant is quite big compared to e.g. Eggs.Variant. Making use of 
the new C++features make it easier and more maintainable.

My bad, I expressed my intent incorrectly. I don't think that Boost must 
follows the experimental proposals. What I believe is that Boost could 
have some experimental libraries that are signaled as such and that can 
have an interface that is not fixed yet.
I would accept Eggs.Variant without even a review (or with a minimal 
review) as an experimental library as part of Boost.Variant after some 
minimal adaptation to fit in Boost of course.

In the Boost.Variant doc there is a section on future directions, about 
the possibility to have a variant with a policy based design.
I'm not sure this is the good way. However I believe that we need 
several kind of variant types that have different characteristics.
We cannot have a variant type that fits all the shoes.

I'm sure that there are some application for which the double storage 
will be the best choice, as there is no heap allocation.
Other applications could prefer that the operations that can not be 
implemented ensuring the strong exception guaranties are just not 
provided if providing them would mean a lost in performances for the 
other operations.

Others are requesting/suggesting an implicit possibly empty variant. 
boost::variant behaves almost already like that when the is a 
boost::blanc type. This possibly empty variant would inherit from some 
of the optional interfaces.

BTW, is boost::variant<T,T> v;  well formed? if yes, what does get<T>(v) 
returns?

I don't know the Boost.Variant implementation but I have a possible 
improvement just from what is documented. I believe that there is yet a 
possible optimization to Temporary heap backup design, consisting in 
reusing the unused memory (if big enough).

Given variant<Ts...> the storage has size max<alignof(Ts)...>.

If we have T stored and we want to assign U and
     sizeof alignof(T)+alignof(U) <= max<alignof(Ts)...> and
     U is nothrow move constructible

we can use the unused memory as double storage and avoid the heap 
allocation/deallocation.

Is that optimization implemented already?

> Instead I'll focus on adding
> missing metaprogramming features (tuple_size, tuple_element) and improving
> free functions (get<Index>(variant), comparisons). Such changes do not
> require separate class.
>
I don't see any conflicts on current discussions index access. Other 
functions that could help if you introduce the index access are the 
emplace functions.

However I don't see why the proposal is specializing tuple_size, 
tuple_element. I will prefer that variant provide a way to get the meta 
tuple of its alternatives, so that you can get its size and the element 
type. A meta function to create a variant type from a meta tuple could 
be useful.

Best,
Vicente