variant has non-trivial destructor even when all constituents have trivial destructor
It seems that boost::variant has non-trivial destructor even for something like boost::variant<int32_t, int64_t>. Thus, It cannot be used in situations that call for a POD where calling the destructor is trivial. Particularly, I can't have a boost::lock_free::queue<boost::variant<X, Y>> even both X and Y are trivially destructible. How about making boost::variant trivially-destructible when everything in it is trivially-destructible?
On 11/26/2015 11:58 PM, ☂Josh Chia (谢任中) wrote:
It seems that boost::variant has non-trivial destructor even for something like boost::variant<int32_t, int64_t>. Thus, It cannot be used in situations that call for a POD where calling the destructor is trivial.
Particularly, I can't have a boost::lock_free::queue<boost::variant<X, Y>> even both X and Y are trivially destructible.
Just making `variant` trivially destructible would not be enough, as `boost::lockfree::queue` also requires a trivial copy-assignment operator.
How about making boost::variant trivially-destructible when everything in it is trivially-destructible?
For your particular use case, it would be far simpler to just use plain old discriminated-unions. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
I used integers only to keep the example simple. In reality I have a few structs with trivial copy-assignment operator and trivial destructor that I make members of the variant. variant lets me use static visitors. If I use my own union with switch statements instead of variant with static visitors, when I add a new type to the union, I may forget to update some switch statement but with static visitors I'll get a compiler error if I forget to update any static visitor. The code may be simpler in some sense if I use a union but it's safer and more maintainable if I use a variant, especially if I would have to maintain many switch statements. I could implement my own static visitor mechanism just for this union-ish type but that seems like reinventing the wheel. So, it would be convenient if I could use boost::lock_free::queue<variant<...>> on my structs, although I have barely any idea on the implementation complexity required. On Fri, Nov 27, 2015 at 11:11 PM, Agustín K-ballo Bergé < kaballo86@hotmail.com> wrote:
On 11/26/2015 11:58 PM, ☂Josh Chia (谢任中) wrote:
It seems that boost::variant has non-trivial destructor even for something like boost::variant<int32_t, int64_t>. Thus, It cannot be used in situations that call for a POD where calling the destructor is trivial.
Particularly, I can't have a boost::lock_free::queue<boost::variant<X, Y>> even both X and Y are trivially destructible.
Just making `variant` trivially destructible would not be enough, as `boost::lockfree::queue` also requires a trivial copy-assignment operator.
How about making boost::variant trivially-destructible when everything
in it is trivially-destructible?
For your particular use case, it would be far simpler to just use plain old discriminated-unions.
Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 11/28/2015 1:27 AM, ☂Josh Chia (谢任中) wrote:
I used integers only to keep the example simple.
In reality I have a few structs with trivial copy-assignment operator and trivial destructor that I make members of the variant. variant lets me use static visitors.
The complexity of the union members don't make the discriminated-union implementation more complex. The number of elements in the union, however, would.
If I use my own union with switch statements instead of variant with static visitors, when I add a new type to the union, I may forget to update some switch statement but with static visitors I'll get a compiler error if I forget to update any static visitor.
The code may be simpler in some sense if I use a union but it's safer and more maintainable if I use a variant, especially if I would have to maintain many switch statements.
Nothing stops you from providing your own switch-driven static visitation. Again, the number of times you'd need to implement this might matter.
I could implement my own static visitor mechanism just for this union-ish type but that seems like reinventing the wheel.
Nod. It's a slightly different shaped wheel. In particular, since the elements will be trivial, you need not -and in fact want not to- implement any special member function. The only thing you'll be needing from `boost::variant` is the discriminator and checked access, everything else it does is just boilerplate overhead (that in your particular use case isn't even needed at all). It could likely still beat having to reinvent a generic wheel by a large factor.
So, it would be convenient if I could use boost::lock_free::queue<variant<...>> on my structs, although I have barely any idea on the implementation complexity required.
It's considerably complex to do it generically given the current language rules. A trivial special member function, if user-declared, must be defaulted in the first definition. Transparent triviality forces splitting the implementation in several different classes that duplicate functionality (not all of it can be abstracted away, e.g. constructors), just to be able to choose between `= default` or `{ ... }` for the one special member function. You can read more about it here: https://akrzemi1.wordpress.com/2012/12/13/constexpr-unions/ Note that the proposed `std::experimental::variant`, as currently specified, won't support your use case either (`variant<int, float>` will be trivially-destructible because `constexpr`, but not trivially-copyable). Concepts will make this trivial: http://melpon.org/wandbox/permlink/mtE1Y1kQcXa3nRXO Until then, you could try working on a patch to make `boost::variant` of trivially-copyable elements trivially-copyable itself. However, if you are looking for a quick turnaround, I suspect going with a plain discriminated-union would get you there considerably faster. That's assuming there's only one or two of these guys that need to be used in a lockfree scenario. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
participants (5)
-
Agustín K-ballo Bergé -
☂Josh Chia (谢任中)