why use meta instead of boost::hana?

[gabyx]

What are the benefits of using meta instead of boost::hana?

I think boost::hana can do the same and much more (glue between compile-time and run-time), and meta ist partially a nice small meta programming library (which only supports compile-time computing, except for meta::for_each) from which everything can be built on top?.

Is there some concense about that? And what do you recommend?

[gnzlbg]

For me the pros of meta are:

• meta is tiny and one header only,
• relatively fast for small type sequences,
• and easy to learn.

So if I just need a way to do better meta-programming over the std <type_traits> meta does a pretty good job for me. Also, if I have range-v3 as a dependency, it comes with meta, so I don't need to add another one. At least for me, adding and managing dependencies in C++ is a pain that I weight heavily.

If I need to do more than just type-level meta-programming, but not much more, range-v3 comes with a lot of tuple-manipulation algorithms so if I am using range-v3 and that suffices, I stay there.

If that doesn't suffices or I am not using range-v3, then I grab Boost.Hana. The pros of Boost.Hana for me are:

• while It's a bigger dependency, it is still header only and self contained, so it is pretty trivial to add it with CMake without pulling in the rest of Boost.
• More algorithms than meta.
• Its algorithms work for types and type-level values, so in hana you need to learn the half than in meta + tuple algorithms, or Boost.MPL + Bust.Fusion.
• Nice docs (nicer than meta), very important if you are a beginner.
• Macros to adapt structs as tuple-like sequences (..._ADAPT_STRUCT_...). If you need this, Hana is better than Boost.Fusion at it.
• Finally, compile-times. If you are doing a lot of meta-programming Hana (and other libraries) compile faster than meta.

[ldionne]

Finally, compile-times. If you are doing a lot of meta-programming Hana (and other libraries) compile faster than meta.

For correctness: I don't think that's true. Hana is actually heavier in terms of compile-times than pure type-level libraries, because it has to support values too and that is rather difficult. But unless you're using a lot of TMP, the difference might not be relevant. The fastest in that area is kvasir::mpl followed closely by brigand.

[brunocodutra]

The ranking might have changed a bit since you last checked http://metaben.ch :)

[gnzlbg]

@brunocodutra

Is there a way to show only benchmarks results for type sequences in range [1, 10] ? (that's mostly the range I actually care about).

[brunocodutra]

@gnzlbg not on metaben.ch, but you could use metabench, the tool under the hood, to benchmark whatever you need.

That said, in that range even boost::MPL is a reasonable choice.