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

Subject: Re: [Boost-users] large variant performance compared (50 elements)
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2011-01-09 15:23:29

Paul wrote:
> Op 9-1-2011 17:29, Steven Watanabe schreef:
>> AMDG
>>
>> On 1/9/2011 6:03 AM, Mathias Gaunard wrote:
>>> 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.
>>
>> So, why not fix Boost.Variant instead of having
>> everyone roll his own?
>>
>> In Christ,
>> Steven Watanabe
> 
> Fully agree on that Steven.
> 
> Would help though to also mention its limitations + rationale in the 
> documentation. It is mentioned to set /Zm on out of memory errors but 
> the root-cause why you got the out-of-memory problem in the first place 
> is not addressed.

I'm not sure which platform you're on, but Christophe Henry found that, 
IIRC, /Gm switch one MSVC was the culprit for large compile/link times 
and memory usage with mpl::vectors with his msm library.

Jeff