Intrinsics for N2965: Type traits and base classes

[Mike Spertus]

OK. Here are some simple benchmarks. I simulated heavy use of reflection 
with 1000 classes that each had about a thousand base classes. I also 
created a super-simple typelist class

template<typename... T> struct typelist {}; // Variadic templates rock

If bases returns a typelist, the program takes about 4 sec.
If bases returns a tuple, the program takes about 4 min.

If I make the program any bigger, the tuple case fails to compile with 
spurious error messages, while the typelist version stays quick.

Given that metaprograms typically create large class hierarchies (look 
at Alexandrescu's CreateScatterHierarchy that he uses to implement 
factory in the Modern C++ design book) and that compile times are an 
enormous obstacle to metaprogramming, I don't think these tests are at 
all ridiculous.

I think this shows we need to return a typelist instead of a tuple.

As I mentioned earlier, I could just return the typelist, or hide it by 
returning an unspecified type (which would actually be a typelist) that 
you would apply a first<> and a rest<> template to walk through. This 
would give us more flexibility for the future (e.g., if a standard 
typelist type is adopted. Likewise, we would be covered if wanted to 
change bases implementation in the future to return an associative 
container. For example, if using size<grep<A, bases<E>::type>>::value to 
count the number of occurrences of A as a base class of E turns out to 
be useful).

Thanks,

Mike

On 9/28/2011 6:54 AM, Mike Spertus wrote:
> Don't worry, I'm not suggesting including boost::mpl at all, just 
> leaving the return type of the bases trait unspecified. IMO, your 
> example illustrates my point that without performance tuning, 
> compiling metaprograms can be prohibitively expensive, so I want to 
> avoid running the tuple metaprogram that creates the fields when we 
> never need to instantiate the type. Benchmarks soon.
>
> Mike
>
> On 9/28/2011 2:53 AM, Jonathan Wakely wrote:
>> On 28 September 2011 04:22, Michael Spertus wrote:
>>> Benjamin,
>>> I think tuple is wrong both for performance reasons (I believe these 
>>> are likely to be serious enough to depress use due to inordinately 
>>> long compiles) and because it prematurely locks us into a rigid 
>>> choice of how our typelists are implemented.
>>>
>>> My inclination is to make it type-independent by returning an 
>>> unspecified type that can have a sequence of types extracted from it 
>>> (this is the approach taken by boost::mpl and has loads of 
>>> experience that shows it is a good approach to metaprogramming). In 
>>> other words, first<bases<A>>::type would be the first base of A, etc.
>> Citing Boost MPL as a good way to avoid inordinately long compiles ...
>> interesting!  Have you ever tried to reduce a GCC bug report from 20k
>> lines to 20, because most Boost libs include every MPL header?!
>>
>> I hope we can get a simple typelist _without_ needing everything else
>> in MPL, such as the apply and lambda metafunctions (and maybe a lot of
>> that could be massively simplified using variadic templates anyway.)
>>
>> .
>>
>