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

Subject: Re: [Boost-users] large variant performance compared (50 elements)
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-01-09 09:03:14

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<shared_ptr<T>  >  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.