Re: [Boost-users] large variant performance compared (50 elements)

On 08/01/2011 23:34, Dave Abrahams wrote:

At Sat, 8 Jan 2011 23:34:47 +0200, Igor R wrote:

...

...

...

If it's really just shared_ptr's in the variant, I would seriously consider replacing it with shared_ptr<void> (with a type tag if necessary). Just a thought.

Seriously, could be a big simplification and speedup vs. using using variant.

Could you please elaborate a bit on this? How to replace variant with shared_ptr<void> and a tag? Wouldn't the tags be wrapped in a variant anyway?

No, tags could be an enum or a type_info*, for example

An enum (or an integer) is a much better idea than a type_info*, since it can be used in a switch statement, and can be mapped naturally to a type in a list of types as an index. Writing a variant replacement is actually quite easy, and doing so would greatly reduce your compile times. Variant is old, full of quirks, and doesn't scale well. Why it even requires its MPL input sequence to be Front Extensible (which it doesn't even state in its documentation) is beyond me. This is a very annoying limitation that makes it impractical to use with a large amount of types, since compatibility with joint_view would be very nice in that situation. The best option is probably to declare your variant-like type using a PP list of types. This way you can directly generate the matching switch statement with minimal overhead. If you need to take a MPL list as input, the best advice is probably to use Steven Watanabe's switch library, as it can generate a switch statement that converts runtime integers into compile-time ones.