Re: [boost] "Simple C++11 metaprogramming"

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

>
> charleyb123 . wrote:
>
>  > http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html
>>
>>
>> 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
feel-your-way-through.

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, "...so 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
them.

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

--charley