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