Miscellaneous Notes

Boost.Variant vs. Boost.Any
Portability
Troubleshooting
Acknowledgments

Boost.Variant vs. Boost.Any

As a discriminated union container, the Variant library shares many of the same features of the Any library. However, since neither library wholly encapsulates the features of the other, one library cannot be generally recommended for use over the other.

That said, Boost.Variant has several advantages over Boost.Any, such as:

Boost.Variant guarantees the type of its content is one of a finite, user-specified set of types.
Boost.Variant provides compile-time checked visitation of its content. (By contrast, the current version of Boost.Any provides no visitation mechanism at all; but even if it did, it would need to be checked at run-time.)
Boost.Variant enables generic visitation of its content. (Even if Boost.Any did provide a visitation mechanism, it would enable visitation only of explicitly-specified types.)
Boost.Variant offers an efficient, stack-based storage scheme (avoiding the overhead of dynamic allocation).

Of course, Boost.Any has several advantages over Boost.Variant, such as:

Boost.Any, as its name implies, allows virtually any type for its content, providing great flexibility.
Boost.Any provides the no-throw guarantee of exception safety for its swap operation.
Boost.Any makes little use of template metaprogramming techniques (avoiding potentially hard-to-read error messages and significant compile-time processor and memory demands).

Portability

The library aims for 100% ANSI/ISO C++ conformance. However, this is strictly impossible due to the inherently non-portable nature of the Type Traits library's type_with_alignment facility. In practice though, no compilers or platforms have been discovered where this reliance on undefined behavior has been an issue.

Additionally, significant effort has been expended to ensure proper functioning despite various compiler bugs and other conformance problems. To date the library testsuite has been compiled and tested successfully on at least the following compilers for basic and advanced functionality:

	Basic	`variant<T&>`	`make_variant_over`	`make_recursive_variant`
Borland C++ 5.5.1 and 5.6.4	X	X
Comeau C++ 4.3.0	X	X	X	X
GNU GCC 3.3.1	X	X	X	X
GNU GCC 2.95.3	X	X		X
Intel C++ 7.0	X		X	X
Metrowerks CodeWarrior 8.3	X		X	X
Microsoft Visual C++ 7.1	X	X	X	X
Microsoft Visual C++ 6 SP5 and 7	X

Finally, the current state of the testsuite in CVS may be found on the Test Summary page. Please note, however, that this page reports on day-to-day changes to inter-release code found in the Boost CVS and thus likely does not match the state of code found in Boost releases.

Troubleshooting

"Template instantiation depth exceeds maximum"
"Internal heap limit reached"

Due to the heavy use of templates in the implementation of variant, it is not uncommon when compiling to encounter problems related to template instantiaton depth, compiler memory, etc. This section attempts to provide advice to common problems experienced on several popular compilers.

(This section is still in progress, with additional advice/feedback welcome. Please post to the Boost-Users list with any useful experiences you may have.)

"Template instantiation depth exceeds maximum"

GNU GCC

GNU GCC

The compiler option -ftemplate-depth-NN can increase the maximum allowed instantiation depth. (Try -ftemplate-depth-50.)

"Internal heap limit reached"

Microsoft Visual C++

Microsoft Visual C++

The compiler option /ZmNNN can increase the memory allocation limit. The NNN is a scaling percentage (i.e., 100 denotes the default limit). (Try /Zm200.)

Acknowledgments

Eric Friedman and Itay Maman designed the initial submission; Eric was the primary implementer.

Eric is also the library maintainer and has expanded upon the initial submission -- adding make_recursive_variant, make_variant_over, support for reference content, etc.

Andrei Alexandrescu's work in [Ale01a] and [Ale02] inspired the library's design.

Jeff Garland was the formal review manager.

Douglas Gregor, Dave Abrahams, Anthony Williams, Fernando Cacciola, Joel de Guzman, Dirk Schreib, Brad King, Giovanni Bajo, Eugene Gladyshev, and others provided helpful feedback and suggestions to refine the semantics, interface, and implementation of the library.