[GSoC] A C++11 enabled TMP library (accepted)
Dear community, I am pleased to announce that my proposal named "A C++11 template metaprogramming library"[1] was accepted for GSoC 2014. I want to thank the community for putting trust in the proposal, and I am committed to do everything I can to make this project succeed. As explained in my proposal, the goal of the project is to build a high quality template metaprogramming library using modern techniques to achieve both higher expressiveness and lower compilation times. Since the ultimate goal is to make such a library part of the Boost distribution, I will try to involve the community and maintain a tight feedback loop. With your support, I am confident that we can achieve a lot in the direction of better template metaprogramming. This is also a good time to mention (advertise?) that I will be presenting the project at the upcoming C++Now conference. :-) I am knee-deep in my finals right now, but updates should come shortly. Stay tuned! Louis Dionne [1]: http://goo.gl/ZlYeFi
On 4/21/2014 4:55 PM, Louis Dionne wrote:
Dear community,
I am pleased to announce that my proposal named "A C++11 template metaprogramming library"[1] was accepted for GSoC 2014. I want to thank the community for putting trust in the proposal, and I am committed to do everything I can to make this project succeed.
As explained in my proposal, the goal of the project is to build a high quality template metaprogramming library using modern techniques to achieve both higher expressiveness and lower compilation times. Since the ultimate goal is to make such a library part of the Boost distribution, I will try to involve the community and maintain a tight feedback loop. With your support, I am confident that we can achieve a lot in the direction of better template metaprogramming.
This is also a good time to mention (advertise?) that I will be presenting the project at the upcoming C++Now conference. :-)
I am knee-deep in my finals right now, but updates should come shortly. Stay tuned!
Please consider making the your library as close as possible usage-wise to the current TMP library so as to make the transition for all the other libraries which use TMP as easy as possible. Thanks for working on a modern version of TMP.
Edward Diener
Please consider making the your library as close as possible usage-wise to the current TMP library so as to make the transition for all the other libraries which use TMP as easy as possible.
Some of the core features of the (current) new library require diverging from the MPL in the following ways: - No more iterators. They do not bring anything performance-wise and they make the implementation of sequences considerably more complicated. - Laziness. This is a key point to improve expressiveness and could also improve performance in some use cases. I'm still investigating on that matter though. - No more implicit lambda expressions. These interact poorly, leading to counterintuitive behavior as in [1]. Usage of aliases could make the problem even worse. There is more, but that is what comes to mind right now. Note that I did reimplement a (rather large) subset of the MPL in a backward compatible fashion before I came to these conclusions. What is definitely possible is to make MPL data types (vector, int_, etc..) compatible with the new library. It should also be possible to make data types from the new library compatible with the old algorithms. That way, you could modernize some metafunctions without having to rewrite the whole metaprogram. I would like to know what other people think about this; I'm making a community probe. Thanks for your input, Louis Dionne [1]: https://svn.boost.org/trac/boost/ticket/8608
On 22 April 2014 14:42, Louis Dionne
Edward Diener
writes: [...]
Please consider making the your library as close as possible usage-wise to the current TMP library so as to make the transition for all the other libraries which use TMP as easy as possible.
Some of the core features of the (current) new library require diverging from the MPL in the following ways: - No more iterators. They do not bring anything performance-wise and they make the implementation of sequences considerably more complicated. - Laziness. This is a key point to improve expressiveness and could also improve performance in some use cases. I'm still investigating on that matter though. - No more implicit lambda expressions. These interact poorly, leading to counterintuitive behavior as in [1]. Usage of aliases could make the problem even worse.
There is more, but that is what comes to mind right now. Note that I did reimplement a (rather large) subset of the MPL in a backward compatible fashion before I came to these conclusions.
What is definitely possible is to make MPL data types (vector, int_, etc..) compatible with the new library. It should also be possible to make data types from the new library compatible with the old algorithms. That way, you could modernize some metafunctions without having to rewrite the whole metaprogram.
I would like to know what other people think about this; I'm making a community probe.
I like your proposed plan, the divergences seem reasonable.
On 2014-04-22 15:42, Louis Dionne wrote:
Some of the core features of the (current) new library require diverging from the MPL in the following ways: - No more iterators. They do not bring anything performance-wise and they make the implementation of sequences considerably more complicated. - Laziness. This is a key point to improve expressiveness and could also improve performance in some use cases. I'm still investigating on that matter though. - No more implicit lambda expressions. These interact poorly, leading to counterintuitive behavior as in [1]. Usage of aliases could make the problem even worse.
I think laziness and explicit lambda expressions are both important changes and make the life of metaprogram authors easier (both for development and debugging metaprograms). I've spent a lot of time debugging issues related to implicit lambda expressions during the development and maintenance of code based on the current MPL. Lazy code is compact and readable, but be careful with its impact on compilation speed and memory usage. It might significantly increase the number of template instantiations you need to make. (See "Boosting MPL with Haskell elements" from last year's C++Now for further details). Regards, Ábel
Abel Sinkovics
Lazy code is compact and readable, but be careful with its impact on compilation speed and memory usage. It might significantly increase the number of template instantiations you need to make. (See "Boosting MPL with Haskell elements" from last year's C++Now for further details).
Thanks for the heads up. Laziness is of course undesirable for inherently strict algorithms. In particular, numeric metafunctions should probably be strict; I'm planning to use a constexpr-based implementation for those. As for sequence algorithms, I'm currently benchmarking several different solutions to try and see what's the best alternative. Regards, Louis
participants (4)
-
Abel Sinkovics -
Edward Diener -
Jonathan Wakely -
Louis Dionne