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

Subject: Re: [Boost-users] large variant performance compared (50 elements)
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-01-10 03:00:28

On 1/10/2011 12:22 PM, Steven Watanabe wrote:
> AMDG
>
> On 1/9/2011 7:57 PM, Joel de Guzman wrote:
>> On 1/10/2011 7:35 AM, Mathias Gaunard wrote:
>>> On 09/01/2011 17:29, Steven Watanabe wrote:
>>>> 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.
>>
>> Agreed. Perhaps it's time for V2 that does not necessarily have to be fully
>> backward compatible.
>
> Why exactly would we need to break backwards
> compatibility? Eliminating the Front Extensible
> requirement shouldn't break anything. I don't
> know of anything in the interface of variant that
> would seriously interfere with a better implementation.
> I know that assignment is a mess, but there's
> a good reason it works the way it does.

Indeed! :-) Also, the Front Extensible quirk is easy to fix. I have code
for it. In fact, I mentioned that Eric Friedman about it at BoostCon.
Compile time? I think that too can be improved without having to rewrite
again from scratch.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net