This section discusses several features of the library often required for advanced uses of variant. Unlike in the above section, each feature presented below is largely independent of the others. Accordingly, this section is not necessarily intended to be read linearly or in its entirety.

While the variant class template's variadic parameter list greatly simplifies use for specific instantiations of the template, it significantly complicates use for generic instantiations. For instance, while it is immediately clear how one might write a function accepting a specific variant instantiation, say variant<int, std::string>, it is less clear how one might write a function accepting any given variant. Due to the lack of support for true variadic template parameter lists in the C++98 standard, the preprocessor is needed. While the Preprocessor library provides a general and powerful solution, the need to repeat BOOST_VARIANT_LIMIT_TYPES unnecessarily clutters otherwise simple code. Therefore, for common use-cases, this library provides its own macro BOOST_VARIANT_ENUM_PARAMS. This macro simplifies for the user the process of declaring variant types in function templates or explicit partial specializations of class templates, as shown in the following: // general cases template <typename T> void some_func(const T &); template <typename T> class some_class; // function template overload template <BOOST_VARIANT_ENUM_PARAMS(typename T)> void some_func(const boost::variant<BOOST_VARIANT_ENUM_PARAMS(T)> &); // explicit partial specialization template <BOOST_VARIANT_ENUM_PARAMS(typename T)> class some_class< boost::variant<BOOST_VARIANT_ENUM_PARAMS(T)> >;

While convenient for typical uses, the variant class template's variadic template parameter list is limiting in two significant dimensions. First, due to the lack of support for true variadic template parameter lists in C++, the number of parameters must be limited to some implementation-defined maximum (namely, BOOST_VARIANT_LIMIT_TYPES). Second, the nature of parameter lists in general makes compile-time manipulation of the lists (metaprogramming) excessively difficult. To solve these problems variant offers the following alternative declaration syntax: variant< type-sequence >. More precisely, if an MPL-compatible sequence is provided as the first argument to variant, the types exposed therein will constitute the set of bounded types for the variant. For instance, typedef mpl::vector< std::string > types_initial; typedef mpl::push_front< types_initial, int >::type types; boost::variant< types > v1; behaves equivalently to boost::variant< int, std::string > v2; Portability: Unfortunately, due to standard conformance issues in several compilers, the alternate declaration syntax described above is not universally available. On these compilers the library indicates its lack of support for the syntax via the definition of the preprocessor symbol BOOST_VARIANT_NO_TYPE_SEQUENCE_SUPPORT.

Recursive types facilitate the construction of complex semantics from simple snytax. For instance, nearly every programmer is familiar with the canonical definition of a linked list implementation, whose simple definition allows sequences of unlimited length: template <typename T> struct list_node { T data; list_node * next; }; The nature of variant as a reusable class template unfortunately precludes the straightforward construction of recursive variant types. Consider for instance a likely initial attempt at construction of a tree structure, which uses std::vector to provide an unlimited number of branches: typedef boost::variant< int , std::vector< /* ??? */ > > int_tree_t; Unlike the list_node example above, int_tree_t isn't in scope until the end of the declaration. The boost::recursive_variant class template solves the problem with clean, meaningful syntax: typedef boost::recursive_variant< int , std::vector< boost::recursive_variant_ > >::type int_tree_t; Note the trailing ::type, accessing the nested type of recursive_variant. This less-than-ideal syntax is required due to the lack of template typedefs in C++98. Once declared, however, use of the resultant variant type is as expected: std::vector< int_tree_t > subresult; subresult.push_back(3); subresult.push_back(5); std::vector< int_tree_t > result; result.push_back(1); result.push_back(subresult); result.push_back(7); int_tree_t var(result); One might represent the resultant content of var as ( 1 ( 3 5 ) 7 ). The "depth" of this tree could of course be greater, and is in fact limited only by available memory. Portability: Unfortunately, due to standard conformance issues in several compilers, recursive_variant is not universally supported. On these compilers the library indicates its lack of support for via the definition of the preprocessor symbol BOOST_VARIANT_NO_FULL_RECURSIVE_VARIANT_SUPPORT.

As the tutorial above demonstrates, visitation is a powerful mechanism for manipulating variant content. Binary visitation further extends the power and flexibility of visitation by allowing simultaneous visitation of the content of two different variant objects. Unfortunately, this feature requires that binary visitors are incompatible with the visitor objects discussed in the tutorial above, as they must operate on two arguments. The following demonstrates the implementation of a binary visitor: class are_strict_equals : public boost::static_visitor<bool> { public: template <typename T, typename U> bool operator()( const T &, const U & ) { return false; // cannot compare different types } template <typename T> bool operator()( const T & lhs, const T & rhs ) { return lhs == rhs; } }; As expected, the visitor is applied to two variant arguments by means of apply_visitor: boost::variant< int, std::string > v1( "hello" ); boost::variant< double, std::string > v2( "hello" ); assert( boost::apply_visitor(are_strict_equals(), v1, v2) ); boost::variant< int, const char * > v3( "hello" ); assert( !boost::apply_visitor(are_strict_equals(), v1, v3) ); Finally, we must note that the function object returned from the "delayed" form of apply_visitor also supports binary visitation, as the following demonstrates: typedef boost::variant<double, std::string> my_variant; std::vector< my_variant > seq1; seq1.push_back("pi is close to "); seq1.push_back(3.14); std::list< my_variant > seq2; seq2.push_back("pi is close to "); seq2.push_back(3.14); are_strict_equals visitor; assert( std::equal( v1.begin(), v1.end(), v2.begin() , boost::apply_visitor( visitor ) ) );