What are the differences between std::variant and boost::variant?
Asked Answered
T

3

21

In an answer to this SO question:

What is the equivalent of boost::variant in the C++ standard library?

it is mentioned that boost::variant and std::variant differ somewhat.

  • What are the differences, as far as someone using these classes is concerned?
  • What motivation did the committee express to adopt std::variant with these differences?
  • What should I watch out for when coding with either of these, to maintain maximum compatibility with switching to the other one?

(the motivation is using boost::variant in pre-C++17 code)

Trochanter answered 23/10, 2016 at 9:19 Comment(4)
@JohnZwinck: Would appreciate your comment/answer seeing how you wrote that answer I linked to.Trochanter
I think JohnZwinck won't get notified unless he's interacted with this question. You might comment on his answer to the other question instead to get his attention.Joella
For those not aware, boost::variant and boost::variant2 are two different libraries. The question is about the former, but it seems worth noting that the official documentation of boost::variant2 states that it is API compatible with std::variant, with some provisos: boost.org/doc/libs/1_75_0/libs/variant2/doc/html/… . See also the Boost project listing at boost.org/doc/libs/1_75_0Octaviaoctavian
@MaxBarraclough: See edit, and also this new question.Trochanter
B
25
  • Assignment/emplacement behavior:

    • boost::variant may allocate memory when performing assignment into a live variant. There are a number of rules that govern when this can happen, so whether a boost::variant will allocate memory depends on the Ts it is instantiated with.

    • std::variant will never dynamically allocate memory. However, as a concession to the complex rules of C++ objects, if an assignment/emplacement throws, then the variant may enter the "valueless_by_exception" state. In this state, the variant cannot be visited, nor will any of the other functions for accessing a specific member work.

      You can only enter this state if assignment/emplacement throws.

  • Boost.Variant includes recursive_variant, which allows a variant to contain itself. They're essentially special wrappers around a pointer to a boost::variant, but they are tied into the visitation machinery.

    std::variant has no such helper type.

  • std::variant offers more use of post-C++11 features. For example:

Beardless answered 23/10, 2016 at 14:33 Comment(7)
Is it possible to add this kind of recursiveness functionality to std::variant without altering the class? (But perhaps with adding stuff to namespace std?)Trochanter
@einpoklum: The point of recursive_variant is that it allows visit to automatically unpack and visit the object it references. Therefore, you would have to build that machinery into std::visit. Which isn't possible without replacing std::visit, which you can't do. Of course, you can always make your own version of std::visit in your own namespace that does the unpacking/visitation.Beardless
I wonder if it's being considered to add the recursive_variant to the std version... at least now that I'm using variants heavily, it seems like being able to make them recursive represents much of their power.Compile
@DanNissenbaum: No proposals have been made towards that end. However, N4450 (pdf) shows that the committee did not think particularly kindly towards it. That being said, now that it's in the standard, it is something that could be revisited. Something the committee might think better on however is a generic mechanism that allows customization of std::visit use. So that you could write your own variant that use that machinery and do your own recursive visitation.Beardless
That's exactly my case - building an AST using Boost.Spirit. It seems so natural to have a recursive variant in that context.Compile
NicolBolas and whoever is reading this - the committe vote on recursive variants was 8 Neutral, 4 Weakly against, 2 Strongly Against. And - the question was "needed?" rather than "desirable?" or "useful?". Indeed, as Nicol suggests, with more people using std::variant this might change. @DanNissenbaum : you could bring this up in the standards mailing list (if not even write an actual proposal).Trochanter
Another difference is boost currently uses std::get with a pointer instead of std::get_if for the non throwing variety.Syllabus
T
5

It seems the main point of contention regarding the design of a variant class has been what should happen when an assignment to the variant, which should upon completion destory the old value, throws an exception:

variant<std::string, MyClassWithThrowingDefaultCtor> v = "ABC";
v = MyClassWithThrowingDefaultCtor();

The options seem to be:

  • Prevent this by restricting the possible representable types to nothrow-move-constructible ones.
  • Keep the old value - but this requires double-buffers.
  • Construct the new value on the heap, store a pointer to it in the variant (so the variant itself is not garbled even on exception). This is, apparently, what boost::variant does.
  • Have a 'disengaged' state with no value for each variant, and go to that state on such failures.
  • Undefined behavior
  • Make the variant throw when trying to read its value after something like that happens

and if I'm not mistaken, the latter is what's been accepted.

This is summarized from the ISO C++ blog post by Axel Naumann from Nov 2015.

Trochanter answered 23/10, 2016 at 10:30 Comment(0)
F
0

std::variant differs slightly from the boost::variant

  • std::variant is declared in the header file rather than in <boost.variant.hpp>
  • std::variant never ever allocates memory
  • std::variant is usable with constexpr
  • Instead of writing boost::get(&variable), you have to write std::get_if(&variable) for std::variant
  • std::variant can not recursively hold itself and misses some other advanced techniques
  • std::variant can in-place construct objects
  • std::variant has index() instead of which()
Fantan answered 27/6, 2021 at 15:17 Comment(1)
Boost.Variant is not part of the C++ standard.Trochanter

© 2022 - 2024 — McMap. All rights reserved.