On 8/13/15 11:44 AM, Eric Niebler wrote:
On 7/16/2015 10:35 AM, Robert Ramey wrote:
On 5/30/15 9:26 AM, Peter Dimov wrote:
I've recently made the mistake to reread Eric Niebler's excellent "Tiny Metaprogramming Library" article
http://ericniebler.com/2014/11/13/tiny-metaprogramming-library/
which of course prompted me to try to experiment with my own tiny metaprogramming library and to see how I'd go about implementing tuple_cat (a challenge Eric gives.)
Ordinarily, any such experiments of mine leave no trace once I abandon them and move on,
We need a permanent place for stuff like this.
but this time I decided to at least write an article about the result, so here it is, with the hope someone might find it useful. :-)
This to me is incredible. I worthy successor to Abraham's and Gurtovoy's MPL book. Clearly C++/11 is going to turnout to be a major game changer with repercussions beyond what we can imagine now.
AFAICT, Peter's code is basically a work-alike of my Meta library [^1] with one feature added (the ability to treat any template instance as a typelist), and one feature removed (metafunction classes and their associated utilities).
To me there is a fundamental difference between Peter's formulation and others such as yours, Hana, and others. I see Peter's document as a "cheat sheet" which describes useful TMP idioms which are supported directly by C++. It shows how far one can go with no library at all. This is useful in a way that a TMP library is not. a) It is extremely helpful as a learning tool. b) It is very useful to one who needs just a little bit of TMP to get over some programming hurdle in the most direct and expedient manner. If one includes one of these idioms in his code, you don't need to include a whole library with a lot of new conceptual overhead. You just have to refer to the Simple C++/TMP document. c) Adding some other library is a bigger deal. It requires reference to more elaborate complete documentation which someone has to maintain. Once someone creates a library, they naturally want to inform it with some conceptual integrity. This makes it better as a library, but then likely requires new concepts and more complete documentation and maintenance. So I see Peter's Cheet sheet as complementing a library solution. It helps users learn the concepts, provides solutions for many problems, but has not pretension to creating a "library". Of course as people become more comfortable with TMP through the use of Peter's cheetsheet, some will eventually move on to creating some more complex metafunctions on their own and/or move to a more complete library solution. In short - I see peter's work as complementing rather than competing with library solutions.
I really believe losing metafunction classes is a significant loss -- not so much because template template parameters are so awful (but they kind of are), but because all the functional composition utilities (bind, compose, curry, uncurry, on, etc.) are so incredibly useful. And also because core issue #1430 [^2] makes it impossible to handle variadic and fixed-arity template aliases uniformly.
Right - If you need this stuff - use a library.
Meta's approach -- borrowed from the MPL -- of quoting template template parameters to turn them into metafunction classes (aka alias classes) puts the workaround for #1430 in one place so that it can be ignored and forgotten.
Which of course is the essence and motivation for creating a library. But Peter's document doesn't purport to be a library. I realize that peter got sucked in to demonstrating how far one could take this - his ego got the best of him and this diluted his point. The power of his document is not that it can do everything - it's that one can do a lot with zero conceptual overhead and very little investment.
But in the end, Peter's and my thinking is pretty aligned wrt metaprogramming in C++11 and beyond.
I think we all agree that C++11+ has opened up lot's of unanticipated new territory in meta programming.
[1]: https://github.com/ericniebler/meta [2]: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1430
Robert Ramey