Re: [boost] Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Subject: Re: [boost] Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem
From: Larry Evans (cppljevans_at_[hidden])
Date: 2015-04-04 07:41:15

On 04/02/2015 07:33 PM, Eric Niebler wrote:
> On 4/2/2015 2:17 PM, Gonzalo BG wrote:
>> I'll briefly chime in to state that I have been using Eric Niebler's
>> tagged_variant for a couple of months now and am very happy with it, it
>> comes with range-v3:
>>
>> https://github.com/ericniebler/range-v3/blob/master/include/range/v3/utility/variant.hpp
>>
>> (note: the utility folder of range-v3 is full of true gems)
> 
> FWIW, I consider it usable, but not fully baked.
> 
Hi Eric.

The code at:

https://github.com/ericniebler/range-v3/blob/master/include/range/v3/utility/variant.hpp#L97

shows variant_data<T,Ts...> is defined recursively.
Wouldn't this cause large compile times?
The reason I say this is because, IIRC, one of the
reasons for the some of the preprocessor use in the current mpl
is to reduce compile times by "chunking" a number
of the T's into a single component in the recursive
inheritance chain.  IIRC, the chunk size in mpl was 10.

Have you seen any compile time problems with this
recursive variant_data?

-regards,
Larry