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