2015-06-26 9:10 GMT+03:00 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr
: 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
Le 26/06/15 08:59, Antony Polukhin a écrit : 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