This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Intrinsics for N2965: Type traits and base classes

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

Yes, compelling.
> 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.

The interface is still simple, I like it.

> 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).

This plan sounds excellent to me.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]