Re: [boost] About all these metaprogramming libraries

Subject: Re: [boost] About all these metaprogramming libraries
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2017-03-19 19:57:03

> If Hana is the slow, "full fat" metaprogramming library,

Hana is not a "slow, full fat" metaprogramming library. Quite far from that.
It's just that for pure type-level metaprogramming (which by the way is
quite rarely needed nowadays with deduced return types), we can't possibly
be as fast as Brigand, Metal or such type-level only solutions that is
highly optimized for that precise use case.

> is there space remaining for exactly one fast, "lightweight"
> metaprogramming library?

The problem is that the term metaprogramming is overloaded to mean several
things. It can either mean pure type-level metaprogramming (MPL world), or
algorithms on tuples (Fusion world). It HAPPENS that the latter is powerful
enough to perform the former; this is what Hana allows and then you only
need one metaprogramming library. However, that is heavier compile-time wise
and does not scale as well as a library that was crafter with type
computations only from the start. And if that was your question, I don't
think you can do what Hana does (i.e. handle Fusion + MPL) while being
significantly faster. You might be able to be some small constant factor
faster, but that's it.

By the way, these libraries for pure type-level metaprogramming have the
same problem, it's just that their constant factors are smaller than Hana's.
Take any of these libraries and try to process a type list with 200K
elements while doing something non-trivial. The fundamental problem is that
we need language-level support for metaprogramming if we want to go
completely crazy with it, and some of us are working exactly on this right
now for C++next (or maybe the one after).

Louis

--
View this message in context: http://boost.2283326.n4.nabble.com/About-all-these-metaprogramming-libraries-tp4692524p4692599.html
Sent from the Boost - Dev mailing list archive at Nabble.com.