Boost logo

Boost :

Subject: Re: [boost] "Simple C++11 metaprogramming"
From: charleyb123 . (charleyb123_at_[hidden])
Date: 2015-05-30 18:32:29

> charleyb123 . wrote:
> >
>> Very nice. Very clean and impressive post.
Peter respondeth:

> Thank you. <snip, read-it-fast>

I happened to be looking at the screen when you posted, and opened the
link. Still, I think it's greatly an attribute of the (very) high quality
of your post. This was my "clean" reference: Your post is very well
written, very well organized, and you express very clear assertions with
supporting rationale and example(s). (Works for me, anyway. ;-))

Bravo -- I'm sure it took you a LONG time to write. There's a lot there,
and you clearly needed to experiment with the compiler quite-a-bit to

Greatly to your credit, I think this an especially timely topic. I've been
thinking about similar things for a while, but not with the clarity and
understanding that you expressed. Your "opening" grabbed my attention:

(a) <snip, historic reference to Boost-MPL and C++03 approaches>

(b) <snip, C++11 changed the playing field because of variadic templates
and associated parameter packs>

IMHO, we're "re-learning" the TMP thing with C++11, C++14, and C++17. I've
been watching Boost-Hana closely, and it's kind of blowing my mind.

I particularly liked these two assertions:
>> (a) mp_size to compute type-list length is a truly generic primitive
>> which is, " nice that [you'd] argue that all our metaprogramming
>> primitives ought to have this property."
>> (b) "Lack-of-higher-order-metaprogramming", suggesting that in C++11 and
>> beyond, we largely should not need metafunctions such as compose, bind, or
>> a lambda library.
> The only problem with (b) is that you can't define a template alias inside
> a function, which I myself found more than a bit annoying. Lambda functions
> a-la Hana have a distinct advantage here - they can be defined inside
> functions.
> Still. :-)

Good point, I'll have to think-on-that. It doesn't take away from your
"main-thrust", though, which is that an extreme elegance is now possible
*without* metafunctions. That's Really Nice, because they seem kind of
"klunky" to me, and I like the idea where we can increasingly get-away from

The other thing that I wanted to mention (which I almost put in my first
response, but then took-it-out) is that I really agree with your approach
to use a prefix ("mp_" in your case) rather than relying on an enclosing
namespace. I agree that it's nice to be able to exercise more control over
exactly what the compiler is finding-and-expanding without worrying about
weird namespace "discoveries". ;-))

Again, thank you very much for the article: It shouts loudly that we have
new and more elegant options for template metaprogramming, and I really
like the direction you suggest.

I really think yours is going to be one of those "classic-posts" that we'll
still be talking about for the next few years. (So, if I ever run into
you, drinks are "on-me" -- you deserve it.)


Boost list run by bdawes at, gregod at, cpdaniel at, john at