Dear Community, About a year ago today, there was a proliferation of threads [1][2][3] in this mailing list concerning the future of Boost.MPL, or even whether it had a future at all, and opinions diverged widely on the matter. Many have expressed concerns about the fact Boost.MPL was long outdated and proposed major changes to open path for modernization, while some others argued against it, fearing unexpected and disastrous side-effects could propagate throughout the rest of Boost. A few questioned if it was worth it at all to spend any further resources on Boost.MPL given the fact new alternatives were coming up, such as Boost.Hana, which departed entirely from template metaprogramming, yet some argued TMP remained a competitive alternative for type computations in C++14 as it has been demonstrated by Peter Dimov in his impressive articles [4] on modern TMP. Amidst all this, a proposal by Robert Ramey [5] caught my attention and inspired me to develop what I call Metal [6], a template metaprogramming library designed on the same core principles as Boost.MPL, but written from the very beginning to take full advantage of C++11. Metal was not designed to be a strict drop in replacement for Boost.MPL though, it was rather meant to be regarded as a modern version of Boost.MPL's original API, diverging only where it could really benefit from modern C++ and that essentially means gains of several orders of magnitude in performance** and lower memory consumption. At this point Metal is very close to where I originally intended to bring it and I think it's time I gauge interest from the community on a modest proposal I've been maturing along the past year. As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead. My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them. This proposal also overcomes the problem of dealing with the maintainability of Boost.MPL, since it provides a way for smooth transition from legacy hacks required by ancient compilers into a cleaner and easier to maintain C++11 codebase, besides avoiding any breaking changes within existing code in the process. Furthermore, should this proposal make it into Boost, I would be naturally willing to take responsibility for the maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for quite some time now, often with limited resources. Comparing Metal and Boost.MPL there are a few noteworthy differences. Metafunction Classes have proven themselves entirely unnecessary and have thus been removed altogether in favour of pure Lambdas (in the Boost.MPL sense). Moreover, iterators make little sense in a functional world, so these too have been removed despite the fact they may easily be emulated in the new design. Moreover Metal develops the concept of optionals, that is, its metafunctions only have a nested ::type defined when they may be successfully computed, what may be safely tested using metal::is_just and may also be used to SFINAE out of miscomputations. Finally I'd like to point out that Metal was designed to be portable across as many compilers as possible and three of the most popular ones are continuously tested using Travis and Appveyor: Clang 3.5+, GCC 4.8+ and MSVC 14 (2015). I hope this is a reasonable proposal and I look forward into your opinions about it. ** Even though I haven't published any benchmarks yet, an example follows just to back my claims regarding performance (just tested on my personal laptop running linux): //Generate a list containing 10 thousand instances of std::integral_constant, from 0 to 9999 using l = metal::enumerate_t<metal::integer<10000>>; // GCC 5.3 ~0.4 s // Clang 3.7 ~0.5 s //Transform a list containing 5 thousand numbers by squaring each element using l1 = metal::enumerate_t<metal::number<long long, 5000>>; using l2 = metal::transform_t<metal::pow<metal::_1, metal::integer<2>>, l1>; // GCC 5.3 ~5.6 s // Clang 3.7 ~3.0 s [1]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257680 [2]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257983 [3]: http://thread.gmane.org/gmane.comp.lib.boost.devel/258843 [4]: http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [5]: http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/ [6]: http://brunocodutra.github.io/metal/ Regards, Bruno Dutra
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal.
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries. One of the reasons for using Boost.MPL is to keep the code compatible with C++03. I assume, with your proposed solution this compatibility will be preserved, won't it? If so, you could branch the implementation based on the language version (or rather, the set of enabled/supported C++11 features). If you don't plan to keep the code compatible with C++03 then I'd rather see Boost.Metal as a completely separate library and Boost.MPL untouched.
2016-02-28 21:13 GMT-03:00 Andrey Semashev <andrey.semashev@gmail.com>:
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal.
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
One of the reasons for using Boost.MPL is to keep the code compatible
with C++03. I assume, with your proposed solution this compatibility will be preserved, won't it? If so, you could branch the implementation based on the language version (or rather, the set of enabled/supported C++11 features).
I don't propose to change anything in the current Boost.MPL nor in its API, just provide an alternative backend for it, hence backward compatibility would always be preserved. Ultimately the more appropriate backend should be selected based on available features, however the user should be given the option to override this behaviour and forcedly specify the desired backend using a preprocessor switch, otherwise it should be completely transparent. New projects should be using API v2, i.e. current Metal, unless for some reason they require C++03, in which case they would have to stick with the older API, i.e. current Boost.MPL. Regards, Bruno
On 2/28/2016 7:13 PM, Andrey Semashev wrote:
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal.
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
I disagree with this. Simply because you are compiling with c++11 on up will not necessarily mean that you want to use the Metal additions to Boost.MPL rather than the current Boost.MPL. Certainly the programmer should have a choice even when C++11 is be used in the compilation.
One of the reasons for using Boost.MPL is to keep the code compatible with C++03. I assume, with your proposed solution this compatibility will be preserved, won't it? If so, you could branch the implementation based on the language version (or rather, the set of enabled/supported C++11 features).
If you don't plan to keep the code compatible with C++03 then I'd rather see Boost.Metal as a completely separate library and Boost.MPL untouched.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2016-02-29 06:48, Edward Diener wrote:
On 2/28/2016 7:13 PM, Andrey Semashev wrote:
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal.
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
I disagree with this. Simply because you are compiling with c++11 on up will not necessarily mean that you want to use the Metal additions to Boost.MPL rather than the current Boost.MPL. Certainly the programmer should have a choice even when C++11 is be used in the compilation.
I don't see a use case where you would want a C++03 implementation on a C++11 capable compiler. On the other hand I can easily see the situation where several libraries using Boost.MPLv2 conflict because they have defined different config macros for it.
On Feb 29, 2016 05:46, "Andrey Semashev" <andrey.semashev@gmail.com> wrote:
On 2016-02-29 06:48, Edward Diener wrote:
On 2/28/2016 7:13 PM, Andrey Semashev wrote:
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal.
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
I disagree with this. Simply because you are compiling with c++11 on up will not necessarily mean that you want to use the Metal additions to Boost.MPL rather than the current Boost.MPL. Certainly the programmer should have a choice even when C++11 is be used in the compilation.
I don't see a use case where you would want a C++03 implementation on a C++11 capable compiler. On the other hand I can easily see the situation where several libraries using Boost.MPLv2 conflict because they have defined different config macros for it.
On the other hand we don't want to break code that has been working for a decade just because it happens to depend on a particular implementation detail that hasn't been ported back from Metal, or perhaps even due to an unnexpected bug in it. For such odd cases, there should be a way to override the default behaviour through the preprocessor and get the code back running, even if temporarily while the code is amended/bugs are fixed. Regards, Bruno
On 2016-02-29 14:45, Bruno Dutra wrote:
On Feb 29, 2016 05:46, "Andrey Semashev" <andrey.semashev@gmail.com> wrote:
On 2016-02-29 06:48, Edward Diener wrote:
On 2/28/2016 7:13 PM, Andrey Semashev wrote:
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
I disagree with this. Simply because you are compiling with c++11 on up will not necessarily mean that you want to use the Metal additions to Boost.MPL rather than the current Boost.MPL. Certainly the programmer should have a choice even when C++11 is be used in the compilation.
I don't see a use case where you would want a C++03 implementation on a C++11 capable compiler. On the other hand I can easily see the situation where several libraries using Boost.MPLv2 conflict because they have defined different config macros for it.
On the other hand we don't want to break code that has been working for a decade just because it happens to depend on a particular implementation detail that hasn't been ported back from Metal, or perhaps even due to an unnexpected bug in it. For such odd cases, there should be a way to override the default behaviour through the preprocessor and get the code back running, even if temporarily while the code is amended/bugs are fixed.
If that's the concern then it's probably better to leave MPL as is and introduce Metal as a separate library. PS: I don't mind breaking code that relies on bugs or implementation details.
On 2/29/2016 3:45 AM, Andrey Semashev wrote:
On 2016-02-29 06:48, Edward Diener wrote:
On 2/28/2016 7:13 PM, Andrey Semashev wrote:
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal.
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
I disagree with this. Simply because you are compiling with c++11 on up will not necessarily mean that you want to use the Metal additions to Boost.MPL rather than the current Boost.MPL. Certainly the programmer should have a choice even when C++11 is be used in the compilation.
I don't see a use case where you would want a C++03 implementation on a C++11 capable compiler. On the other hand I can easily see the situation where several libraries using Boost.MPLv2 conflict because they have defined different config macros for it.
I have a library with current MPL code. Someone compiles my library in C++11 mode. Is that a good enough use case for you ? Or are you going to insist that I rewrite my library using Metal even though it works perfectly well in C++11 mode as is ? I am not against possibly eventually changing my library to use Metal. But telling me that my library should be broken because Metal exists is absurd.
On 2016-02-29 20:18, Edward Diener wrote:
On 2/29/2016 3:45 AM, Andrey Semashev wrote:
On 2016-02-29 06:48, Edward Diener wrote:
On 2/28/2016 7:13 PM, Andrey Semashev wrote:
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal.
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
I disagree with this. Simply because you are compiling with c++11 on up will not necessarily mean that you want to use the Metal additions to Boost.MPL rather than the current Boost.MPL. Certainly the programmer should have a choice even when C++11 is be used in the compilation.
I don't see a use case where you would want a C++03 implementation on a C++11 capable compiler. On the other hand I can easily see the situation where several libraries using Boost.MPLv2 conflict because they have defined different config macros for it.
I have a library with current MPL code. Someone compiles my library in C++11 mode. Is that a good enough use case for you ? Or are you going to insist that I rewrite my library using Metal even though it works perfectly well in C++11 mode as is ?
I'm not sure I see the problem. The way I understood the OP, the proposed Metal backend for MPL is transparent to the users of MPL. I.e. your library will still be using mpl:: components the same way, whether or not they are actually implemented by the legacy code or the C++11 new one.
I am not against possibly eventually changing my library to use Metal. But telling me that my library should be broken because Metal exists is absurd.
I wasn't saying that it should. If anything, my comments so far in this thread have been against touching MPL if it means breaking compatibility (besides bugs and implementation details, that is). Selecting the non-backwards-compatible code by defining a macro is not an acceptable solution to me.
On 2/29/2016 3:45 AM, Andrey Semashev wrote:
On 2016-02-29 06:48, Edward Diener wrote:
On 2/28/2016 7:13 PM, Andrey Semashev wrote:
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal.
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
I disagree with this. Simply because you are compiling with c++11 on up will not necessarily mean that you want to use the Metal additions to Boost.MPL rather than the current Boost.MPL. Certainly the programmer should have a choice even when C++11 is be used in the compilation.
I don't see a use case where you would want a C++03 implementation on a C++11 capable compiler. On the other hand I can easily see the situation where several libraries using Boost.MPLv2 conflict because they have defined different config macros for it.
You have a good point with your last sentence. The best thing might be to put the MPLv2 header files in its own separate version2 sub-directory structure.
On 2016-02-29 20:39, Edward Diener wrote:
On 2/29/2016 3:45 AM, Andrey Semashev wrote:
On 2016-02-29 06:48, Edward Diener wrote:
On 2/28/2016 7:13 PM, Andrey Semashev wrote:
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal.
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
I disagree with this. Simply because you are compiling with c++11 on up will not necessarily mean that you want to use the Metal additions to Boost.MPL rather than the current Boost.MPL. Certainly the programmer should have a choice even when C++11 is be used in the compilation.
I don't see a use case where you would want a C++03 implementation on a C++11 capable compiler. On the other hand I can easily see the situation where several libraries using Boost.MPLv2 conflict because they have defined different config macros for it.
You have a good point with your last sentence. The best thing might be to put the MPLv2 header files in its own separate version2 sub-directory structure.
...and its own separate namespace. With that, it doesn't really differ from a completely separate library, which I was suggesting. No need to drag the MPLv2 naming as well.
2016-02-29 16:42 GMT-03:00, Andrey Semashev <andrey.semashev@gmail.com>:
On 2016-02-29 20:39, Edward Diener wrote:
On 2/29/2016 3:45 AM, Andrey Semashev wrote:
On 2016-02-29 06:48, Edward Diener wrote:
On 2/28/2016 7:13 PM, Andrey Semashev wrote:
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal.
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
I disagree with this. Simply because you are compiling with c++11 on up will not necessarily mean that you want to use the Metal additions to Boost.MPL rather than the current Boost.MPL. Certainly the programmer should have a choice even when C++11 is be used in the compilation.
I don't see a use case where you would want a C++03 implementation on a C++11 capable compiler. On the other hand I can easily see the situation where several libraries using Boost.MPLv2 conflict because they have defined different config macros for it.
You have a good point with your last sentence. The best thing might be to put the MPLv2 header files in its own separate version2 sub-directory structure.
...and its own separate namespace. With that, it doesn't really differ from a completely separate library, which I was suggesting. No need to drag the MPLv2 naming as well.
Well I would insist in my original proposal, because otherwise we wouldn't achieve my the desired goal to effectively modernize Boost.MPL. I understand your concerns, they are perfectly reasonable, but please bear in mind that the selection of the more appropriate backend *shall* be automatic and totally transparent to the user. A preprocessor switch to override this behaviour would be meant only for an *exceptional situation* where the user must get the code back in production and while the issues which prevent the automatic selection of backends is addressed. Otherwise, should anything go wrong for whatever reason, the user would have no alternative but to revert to a previous release of the entire Boost distribution just to get the code back compiling. At any rate, should the community deem the risk of adding such a preprocessor switch much too high, I would not go against it at all. Regards, Bruno Dutra
2016-02-29 14:39 GMT-03:00, Edward Diener <eldiener@tropicsoft.com>:
On 2/29/2016 3:45 AM, Andrey Semashev wrote:
On 2016-02-29 06:48, Edward Diener wrote:
On 2/28/2016 7:13 PM, Andrey Semashev wrote:
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal.
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
I disagree with this. Simply because you are compiling with c++11 on up will not necessarily mean that you want to use the Metal additions to Boost.MPL rather than the current Boost.MPL. Certainly the programmer should have a choice even when C++11 is be used in the compilation.
I don't see a use case where you would want a C++03 implementation on a C++11 capable compiler. On the other hand I can easily see the situation where several libraries using Boost.MPLv2 conflict because they have defined different config macros for it.
You have a good point with your last sentence. The best thing might be to put the MPLv2 header files in its own separate version2 sub-directory structure.
I don’t meant to say you got it wrong, on the contrary I’m certain you got it right, but before we start misunderstanding ourselves, allow me to clarify some terminology so it is clear to everyone. * Currently Boost.MPL has one API which we all know and love. I call it API v1. * API v1 has currently only one implementation, which is, naturally, that provided by Boost.MPL. * I propose to provide another implementation for API v1 based on Metal, that could be used when the compiler supports C++11. This alternative backend would bring the benefit of faster compilation times and lower memory consumption to older projects. * I also propose to define a new API v2, which is basically that of Metal as it is now, and which would be encouraged for new projects. * Boost.MPL2 in this context would be this new revision of Boost.MPL which has two APIs, v1 and v2, and two implementations for API v1. I really hope that makes it a bit clearer for everyone. Regards, Bruno Dutra
On 2/29/2016 2:50 PM, Bruno Dutra wrote:
2016-02-29 14:39 GMT-03:00, Edward Diener <eldiener@tropicsoft.com>:
On 2/29/2016 3:45 AM, Andrey Semashev wrote:
On 2016-02-29 06:48, Edward Diener wrote:
On 2/28/2016 7:13 PM, Andrey Semashev wrote:
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal.
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
I disagree with this. Simply because you are compiling with c++11 on up will not necessarily mean that you want to use the Metal additions to Boost.MPL rather than the current Boost.MPL. Certainly the programmer should have a choice even when C++11 is be used in the compilation.
I don't see a use case where you would want a C++03 implementation on a C++11 capable compiler. On the other hand I can easily see the situation where several libraries using Boost.MPLv2 conflict because they have defined different config macros for it.
You have a good point with your last sentence. The best thing might be to put the MPLv2 header files in its own separate version2 sub-directory structure.
I don’t meant to say you got it wrong, on the contrary I’m certain you got it right, but before we start misunderstanding ourselves, allow me to clarify some terminology so it is clear to everyone.
* Currently Boost.MPL has one API which we all know and love. I call it API v1. * API v1 has currently only one implementation, which is, naturally, that provided by Boost.MPL. * I propose to provide another implementation for API v1 based on Metal, that could be used when the compiler supports C++11. This alternative backend would bring the benefit of faster compilation times and lower memory consumption to older projects.
As long as the Metal API v1 has the exact same syntax, where it exists, as the current MPL, there should be no problem with what you propose. In that case I agree with Andrey that the level of c++, whether c++11 on up or not, can determine whether the current MPL is used or the Metal API v1 is used, for the syntax involved. My concern is simply that current Boost libraries which use MPL, of which there are quite a few as you know, not be forced to change syntactically when Metal is integrated with MPL.
* I also propose to define a new API v2, which is basically that of Metal as it is now, and which would be encouraged for new projects. * Boost.MPL2 in this context would be this new revision of Boost.MPL which has two APIs, v1 and v2, and two implementations for API v1.
Sounds good to me.
I really hope that makes it a bit clearer for everyone.
2016-02-29 19:11 GMT-03:00 Edward Diener <eldiener@tropicsoft.com>:
On 2/29/2016 2:50 PM, Bruno Dutra wrote:
2016-02-29 14:39 GMT-03:00, Edward Diener <eldiener@tropicsoft.com>:
On 2/29/2016 3:45 AM, Andrey Semashev wrote:
On 2016-02-29 06:48, Edward Diener wrote:
On 2/28/2016 7:13 PM, Andrey Semashev wrote:
On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra@gmail.com> wrote:
> Dear Community, >
[snip]
My proposal is to make Metal officially into a new revision of > Boost.MPL's > API, essentially MPL2 as the original proposal by Robert Ramey put > it, > merging both into one single TMP library. The idea would be to > provide a > thin proxy for the current Boost.MPL API which would have two > backends > configurable by preprocessor switches: the original implementation > and a > another one based on Metal. >
I don't think it needs to be controlled with preprocessor switches. In fact, it's best to avoid config macros as much as possible because it complicates the use of the library in other libraries.
I disagree with this. Simply because you are compiling with c++11 on up will not necessarily mean that you want to use the Metal additions to Boost.MPL rather than the current Boost.MPL. Certainly the programmer should have a choice even when C++11 is be used in the compilation.
I don't see a use case where you would want a C++03 implementation on a C++11 capable compiler. On the other hand I can easily see the situation where several libraries using Boost.MPLv2 conflict because they have defined different config macros for it.
You have a good point with your last sentence. The best thing might be to put the MPLv2 header files in its own separate version2 sub-directory structure.
I don’t meant to say you got it wrong, on the contrary I’m certain you got it right, but before we start misunderstanding ourselves, allow me to clarify some terminology so it is clear to everyone.
* Currently Boost.MPL has one API which we all know and love. I call it API v1. * API v1 has currently only one implementation, which is, naturally, that provided by Boost.MPL. * I propose to provide another implementation for API v1 based on Metal, that could be used when the compiler supports C++11. This alternative backend would bring the benefit of faster compilation times and lower memory consumption to older projects.
As long as the Metal API v1 has the exact same syntax, where it exists, as the current MPL, there should be no problem with what you propose. In that case I agree with Andrey that the level of c++, whether c++11 on up or not, can determine whether the current MPL is used or the Metal API v1 is used, for the syntax involved. My concern is simply that current Boost libraries which use MPL, of which there are quite a few as you know, not be forced to change syntactically when Metal is integrated with MPL.
Exactly, I pose it as a prerequisite that using Metal as a backend for the current API v1 shall not break any existing code. Bruno Dutra
On 2/28/2016 6:17 PM, Bruno Dutra wrote:
Dear Community,
About a year ago today, there was a proliferation of threads [1][2][3] in this mailing list concerning the future of Boost.MPL, or even whether it had a future at all, and opinions diverged widely on the matter. Many have expressed concerns about the fact Boost.MPL was long outdated and proposed major changes to open path for modernization, while some others argued against it, fearing unexpected and disastrous side-effects could propagate throughout the rest of Boost. A few questioned if it was worth it at all to spend any further resources on Boost.MPL given the fact new alternatives were coming up, such as Boost.Hana, which departed entirely from template metaprogramming, yet some argued TMP remained a competitive alternative for type computations in C++14 as it has been demonstrated by Peter Dimov in his impressive articles [4] on modern TMP.
Amidst all this, a proposal by Robert Ramey [5] caught my attention and inspired me to develop what I call Metal [6], a template metaprogramming library designed on the same core principles as Boost.MPL, but written from the very beginning to take full advantage of C++11. Metal was not designed to be a strict drop in replacement for Boost.MPL though, it was rather meant to be regarded as a modern version of Boost.MPL's original API, diverging only where it could really benefit from modern C++ and that essentially means gains of several orders of magnitude in performance** and lower memory consumption. At this point Metal is very close to where I originally intended to bring it and I think it's time I gauge interest from the community on a modest proposal I've been maturing along the past year.
As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead.
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them.
This proposal also overcomes the problem of dealing with the maintainability of Boost.MPL, since it provides a way for smooth transition from legacy hacks required by ancient compilers into a cleaner and easier to maintain C++11 codebase, besides avoiding any breaking changes within existing code in the process. Furthermore, should this proposal make it into Boost, I would be naturally willing to take responsibility for the maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for quite some time now, often with limited resources.
I would very much welcome your proposal, especially if you take on the maintenance of Boost.MPL for which I believe you are easily qualified to do. I would suggest in the beginning that the current Boost.MPL be the default and the Metal changes you make to it be controlled by a particular preprocessor switch and, of course, the need to compile using C++11 on up. Eventually you can make Metal the default whenever C++11 on up is used, and the current Boost.MPL the default whenever C++11 on up is not being used or a particular preprocessor switch is specified.
Comparing Metal and Boost.MPL there are a few noteworthy differences. Metafunction Classes have proven themselves entirely unnecessary and have thus been removed altogether in favour of pure Lambdas (in the Boost.MPL sense). Moreover, iterators make little sense in a functional world, so these too have been removed despite the fact they may easily be emulated in the new design. Moreover Metal develops the concept of optionals, that is, its metafunctions only have a nested ::type defined when they may be successfully computed, what may be safely tested using metal::is_just and may also be used to SFINAE out of miscomputations.
Finally I'd like to point out that Metal was designed to be portable across as many compilers as possible and three of the most popular ones are continuously tested using Travis and Appveyor: Clang 3.5+, GCC 4.8+ and MSVC 14 (2015).
I hope this is a reasonable proposal and I look forward into your opinions about it.
** Even though I haven't published any benchmarks yet, an example follows just to back my claims regarding performance (just tested on my personal laptop running linux):
//Generate a list containing 10 thousand instances of std::integral_constant, from 0 to 9999 using l = metal::enumerate_t<metal::integer<10000>>;
// GCC 5.3 ~0.4 s // Clang 3.7 ~0.5 s
//Transform a list containing 5 thousand numbers by squaring each element using l1 = metal::enumerate_t<metal::number<long long, 5000>>; using l2 = metal::transform_t<metal::pow<metal::_1, metal::integer<2>>, l1>;
// GCC 5.3 ~5.6 s // Clang 3.7 ~3.0 s
[1]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257680 [2]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257983 [3]: http://thread.gmane.org/gmane.comp.lib.boost.devel/258843 [4]: http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [5]: http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/ [6]: http://brunocodutra.github.io/metal/
Regards, Bruno Dutra
On Feb 29, 2016 00:45, "Edward Diener" <eldiener@tropicsoft.com> wrote:
On 2/28/2016 6:17 PM, Bruno Dutra wrote:
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of
API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them.
This proposal also overcomes the problem of dealing with the maintainability of Boost.MPL, since it provides a way for smooth
from legacy hacks required by ancient compilers into a cleaner and easier to maintain C++11 codebase, besides avoiding any breaking changes within existing code in the process. Furthermore, should this proposal make it into Boost, I would be naturally willing to take responsibility for the maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for quite some time now, often with limited resources.
I would very much welcome your proposal, especially if you take on the
I would suggest in the beginning that the current Boost.MPL be the default and the Metal changes you make to it be controlled by a particular
Boost.MPL's transition maintenance of Boost.MPL for which I believe you are easily qualified to do. I appreciate it. preprocessor switch and, of course, the need to compile using C++11 on up. Eventually you can make Metal the default whenever C++11 on up is used, and the current Boost.MPL the default whenever C++11 on up is not being used or a particular preprocessor switch is specified. Yes, that's precisely what I propose. Regards, Bruno
Gesendet: Montag, 29. Februar 2016 um 00:17 Uhr Von: "Bruno Dutra" <brunocodutra@gmail.com> An: boost@lists.boost.org Betreff: [boost] [MPL] A Proposal
Dear Community,
About a year ago today, there was a proliferation of threads [1][2][3] in this mailing list concerning the future of Boost.MPL, or even whether it had a future at all, and opinions diverged widely on the matter. Many have expressed concerns about the fact Boost.MPL was long outdated and proposed major changes to open path for modernization, while some others argued against it, fearing unexpected and disastrous side-effects could propagate throughout the rest of Boost. A few questioned if it was worth it at all to spend any further resources on Boost.MPL given the fact new alternatives were coming up, such as Boost.Hana, which departed entirely from template metaprogramming, yet some argued TMP remained a competitive alternative for type computations in C++14 as it has been demonstrated by Peter Dimov in his impressive articles [4] on modern TMP.
Amidst all this, a proposal by Robert Ramey [5] caught my attention and inspired me to develop what I call Metal [6], a template metaprogramming library designed on the same core principles as Boost.MPL, but written from the very beginning to take full advantage of C++11. Metal was not designed to be a strict drop in replacement for Boost.MPL though, it was rather meant to be regarded as a modern version of Boost.MPL's original API, diverging only where it could really benefit from modern C++ and that essentially means gains of several orders of magnitude in performance** and lower memory consumption. At this point Metal is very close to where I originally intended to bring it and I think it's time I gauge interest from the community on a modest proposal I've been maturing along the past year.
As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead.
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them.
This proposal also overcomes the problem of dealing with the maintainability of Boost.MPL, since it provides a way for smooth transition from legacy hacks required by ancient compilers into a cleaner and easier to maintain C++11 codebase, besides avoiding any breaking changes within existing code in the process. Furthermore, should this proposal make it into Boost, I would be naturally willing to take responsibility for the maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for quite some time now, often with limited resources.
Whats the difference between your metal library and the Brigand library by Edouard Aligand and Joel Falcou, also written for a similar purpose: to replace boost.MPL? Do you compile as fast as Brigand? thanks, Jens Weller Brigand: https://github.com/edouarda/brigand
2016-02-29 6:37 GMT-03:00, Jens Weller <JensWeller@gmx.de>:
Gesendet: Montag, 29. Februar 2016 um 00:17 Uhr Von: "Bruno Dutra" <brunocodutra@gmail.com> An: boost@lists.boost.org Betreff: [boost] [MPL] A Proposal
Dear Community,
[snip]
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them.
This proposal also overcomes the problem of dealing with the maintainability of Boost.MPL, since it provides a way for smooth transition from legacy hacks required by ancient compilers into a cleaner and easier to maintain C++11 codebase, besides avoiding any breaking changes within existing code in the process. Furthermore, should this proposal make it into Boost, I would be naturally willing to take responsibility for the maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for quite some time now, often with limited resources.
Whats the difference between your metal library and the Brigand library by Edouard Aligand and Joel Falcou, also written for a similar purpose: to replace boost.MPL?
I must admit I wasn’t aware of the existence of Brigand up until now. At a first glance I can see that Brigand, just like Eric Niebler's Meta, departs from the lazy design of Boost.MPL and Metal in that it appears to impose eager evaluation of metafunctions instead of requiring explicit evaluation via typename $::type. It might be that Boost.MPL was so designed because at the time there were no alias templates, but the lazy design does have several advantages in my opinion. First of all, it enables the natural definition of Lambdas as unevaluated metafunctions [1]. Moreover, by defining lists as simply unevaluated metafunctions, Metal essentially erases the distinction between data structures and the algorithms themselves [2]. This interesting property known as Homoiconicity is often credited for the expressiveness and flexibility of Lisp. Finally, unevaluated metafunctions can also be regarded as optionals that either define a nested ::type, if they can be successfully computed, or not, if some precondition is not met, e.g. trying to access an element of an empty list. This way metafunctions may be safely tested using metal::is_just before being evaluated, without requiring explicit use of SFINAE. Besides, the verbosity of typing typename $::type can be totally overcome by using the C++14 notation and defining alias templates ended by _t as eager versions of metafunctions. Please refer to [3] for the definition of lists, optionals, expressions (metafunctions), etc., for an overall idea of Metal's design. Of course this is just a very shallow and biased comparison between Metal and Bringad. I’ll be sure to watch their presentation and better understand their approach before I can more accurately compare Metal with it.
Do you compile as fast as Brigand?
My next efforts will be directed toward developing a framework for running banchmarks. I'll be sure to add Brigand, as well as other alternatives of which I am aware, for comparison purposes. [1]: http://www.boost.org/doc/libs/1_60_0/libs/mpl/doc/refmanual/lambda-expressio... [2]: http://brunocodutra.github.io/metal/#duality [3]: http://brunocodutra.github.io/metal/#concepts Regards, Bruno Dutra
Bruno Dutra <brunocodutra <at> gmail.com> writes:
[...]
Do you compile as fast as Brigand?
My next efforts will be directed toward developing a framework for running banchmarks. I'll be sure to add Brigand, as well as other alternatives of which I am aware, for comparison purposes.
I've spent a _huge_ amount of time setting up a system for doing compile-time benchmarks with Hana (and MPL11 before that). What I ended up with works well, but it's not perfect and I would definitely enjoy something that's less coupled to Hana. I know a couple of persons that could also use this. Before you go down that road, I suggest we talk and perhaps make it a joint effort. Louis
2016-02-29 11:46 GMT-03:00 Louis Dionne <ldionne.2@gmail.com>:
Bruno Dutra <brunocodutra <at> gmail.com> writes:
[...]
Do you compile as fast as Brigand?
My next efforts will be directed toward developing a framework for running banchmarks. I'll be sure to add Brigand, as well as other alternatives of which I am aware, for comparison purposes.
I've spent a _huge_ amount of time setting up a system for doing compile-time benchmarks with Hana (and MPL11 before that). What I ended up with works well, but it's not perfect and I would definitely enjoy something that's less coupled to Hana. I know a couple of persons that could also use this. Before you go down that road, I suggest we talk and perhaps make it a joint effort.
That is a good idea indeed! I’ve seen what you did on Boost.Hana and, even though I am erb illiterate, I managed to hijack it locally on my laptop to run a few benchmarks on Metal. Anyways I don’t think it would be too hard to evolve it into an independent CMake module, or do you have a different idea in your mind? I'll contact you off the list so we can better discuss this idea. Regards, Bruno Dutra
On Mon, Feb 29, 2016 at 1:52 PM, Bruno Dutra <brunocodutra@gmail.com>
[snip]
2016-02-29 6:37 GMT-03:00, Jens Weller <JensWeller@gmx.de>:
[snip] Do you compile as fast as Brigand?
My next efforts will be directed toward developing a framework for running benchmarks. I'll be sure to add Brigand, as well as other alternatives of which I am aware, for comparison purposes.
At last, after almost 9 months, I think it is time I properly address this question. It is unfortunate that it took so long, but up until recently the compile time performance of metaprogramming libraries simply couldn't be assessed due to the lack of proper tooling and arguing on this matter would have been in vain. As some of you may know from some of his talks, Louis Dionne and I decided to team up and develop a comprehensive yet simple set of tools that would make it easy to benchmark metaprogramming techniques and as such provide feedback to the development of faster metaprogramming libraries. This is how Metabench came to be, in very few words a drop in CMake module that provides a concise API to generate charts out of compile time benchmarks. Using Metabench we then set up a comprehensive collection of compile time benchmarks to assess the performance of well known metaprogramming libraries (currently Boost.MPL, Boost.Fusion, Boost.Hana, Metal, Meta and Brigand), whose up to date results for several versions of GCC and Clang are published daily at Metaben.ch [1]. Now, finally, back to the question: Yes, Metal compiles just as fast as Brigand on both Clang and GCC and even considerably faster for some algorithms [1]. I should also mention that meanwhile I have completely overhauled Metal a few too many times already to make sure I explored all the possibilities modern C++ offers TMP and even though it's still subject to some minor refactoring, I'm confident that its current API is close to what will eventually make it to a stable release. In fact I've already written most of the reference documentation as I don't expect it to change significantly anymore and as such I'd like to invite all of those interested in metaprogramming to take a look at it [2]. Any feedback will be greatly appreciated. [1]: http://metaben.ch/ [2]: http://brunocodutra.github.io/metal/ Regards, Bruno
On 11/12/2016 5:26 PM, Bruno Dutra wrote:
On Mon, Feb 29, 2016 at 1:52 PM, Bruno Dutra <brunocodutra@gmail.com>
[snip]
2016-02-29 6:37 GMT-03:00, Jens Weller <JensWeller@gmx.de>:
[snip] Do you compile as fast as Brigand?
My next efforts will be directed toward developing a framework for running benchmarks. I'll be sure to add Brigand, as well as other alternatives of which I am aware, for comparison purposes.
At last, after almost 9 months, I think it is time I properly address this question. It is unfortunate that it took so long, but up until recently the compile time performance of metaprogramming libraries simply couldn't be assessed due to the lack of proper tooling and arguing on this matter would have been in vain.
As some of you may know from some of his talks, Louis Dionne and I decided to team up and develop a comprehensive yet simple set of tools that would make it easy to benchmark metaprogramming techniques and as such provide feedback to the development of faster metaprogramming libraries. This is how Metabench came to be, in very few words a drop in CMake module that provides a concise API to generate charts out of compile time benchmarks.
Using Metabench we then set up a comprehensive collection of compile time benchmarks to assess the performance of well known metaprogramming libraries (currently Boost.MPL, Boost.Fusion, Boost.Hana, Metal, Meta and Brigand), whose up to date results for several versions of GCC and Clang are published daily at Metaben.ch [1].
Now, finally, back to the question: Yes, Metal compiles just as fast as Brigand on both Clang and GCC and even considerably faster for some algorithms [1].
I should also mention that meanwhile I have completely overhauled Metal a few too many times already to make sure I explored all the possibilities modern C++ offers TMP and even though it's still subject to some minor refactoring, I'm confident that its current API is close to what will eventually make it to a stable release. In fact I've already written most of the reference documentation as I don't expect it to change significantly anymore and as such I'd like to invite all of those interested in metaprogramming to take a look at it [2]. Any feedback will be greatly appreciated.
[1]: http://metaben.ch/ [2]: http://brunocodutra.github.io/metal/
A quick note. Since the latest released clang version is 3.9 and the latest released gcc version is 6.2, wouldn't it be better if metal was tested with these versions. I also noticed that Travis CI uses old versions of both clang and gcc, so I wonder why so much software is still using old versions when new, better ones are available, especially as relates to C++11 on up support.
On Sun, Nov 13, 2016 at 6:47 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 11/12/2016 5:26 PM, Bruno Dutra wrote:
On Mon, Feb 29, 2016 at 1:52 PM, Bruno Dutra <brunocodutra@gmail.com>
[snip]
2016-02-29 6:37 GMT-03:00, Jens Weller <JensWeller@gmx.de>:
[snip] Do you compile as fast as Brigand?
My next efforts will be directed toward developing a framework for running benchmarks. I'll be sure to add Brigand, as well as other alternatives of which I am aware, for comparison purposes.
[snip]
Now, finally, back to the question: Yes, Metal compiles just as fast as Brigand on both Clang and GCC and even considerably faster for some algorithms [1].
I should also mention that meanwhile I have completely overhauled Metal a few too many times already to make sure I explored all the possibilities modern C++ offers TMP and even though it's still subject to some minor refactoring, I'm confident that its current API is close to what will eventually make it to a stable release. In fact I've already written most of the reference documentation as I don't expect it to change significantly anymore and as such I'd like to invite all of those interested in metaprogramming to take a look at it [2]. Any feedback will be greatly appreciated.
[1]: http://metaben.ch/ [2]: http://brunocodutra.github.io/metal/
A quick note. Since the latest released clang version is 3.9 and the latest released gcc version is 6.2, wouldn't it be better if metal was tested with these versions.
Metal itself is setup to run unit tests on Clang 3.9 on Travis CI [1], but unfortunately that version of Clang is still not supported on their recommended container-based images [2]. For that same reason we are currently unable to publish benchmark data for Clang 3.9 compiler on metaben.ch. Regarding GCC, Metal is in fact tested on version 6.2 on Travis [3], but due to some recent changing in the versioning scheme of GCC, Ubuntu abolished the minor version from their packaging of GCC, which means GCC 6 translates to the latest minor release, currently 6.2. Likewise GCC 5 currently translates to 5.4. The same goes for benchmark results published on metaben.ch.
I also noticed that Travis CI uses old versions of both clang and gcc, so I wonder why so much software is still using old versions when new, better ones are available, especially as relates to C++11 on up support.
I believe Travis CI provides the original versions of development tools that are available by default on the OS images they use. Since their recommended container-based environment still runs on Ubuntu 12.04, one can imagine that the versions of GCC and Clang available there are pretty ancient by now. One can always install more recent versions of compilers from some selected external sources, but that must go through a process of whitelisting, which unfortunately takes much too long sometimes. [1]: https://github.com/brunocodutra/metal/blob/master/.travis.yml#L83 [2]: https://github.com/travis-ci/apt-source-whitelist/issues/300 [3]: https://travis-ci.org/brunocodutra/metal/jobs/166841250#L563
On 11/13/2016 7:22 AM, Bruno Dutra wrote:
On Sun, Nov 13, 2016 at 6:47 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 11/12/2016 5:26 PM, Bruno Dutra wrote:
On Mon, Feb 29, 2016 at 1:52 PM, Bruno Dutra <brunocodutra@gmail.com>
[snip]
2016-02-29 6:37 GMT-03:00, Jens Weller <JensWeller@gmx.de>:
[snip] Do you compile as fast as Brigand?
My next efforts will be directed toward developing a framework for running benchmarks. I'll be sure to add Brigand, as well as other alternatives of which I am aware, for comparison purposes.
[snip]
Now, finally, back to the question: Yes, Metal compiles just as fast as Brigand on both Clang and GCC and even considerably faster for some algorithms [1].
I should also mention that meanwhile I have completely overhauled Metal a few too many times already to make sure I explored all the possibilities modern C++ offers TMP and even though it's still subject to some minor refactoring, I'm confident that its current API is close to what will eventually make it to a stable release. In fact I've already written most of the reference documentation as I don't expect it to change significantly anymore and as such I'd like to invite all of those interested in metaprogramming to take a look at it [2]. Any feedback will be greatly appreciated.
[1]: http://metaben.ch/ [2]: http://brunocodutra.github.io/metal/
A quick note. Since the latest released clang version is 3.9 and the latest released gcc version is 6.2, wouldn't it be better if metal was tested with these versions.
Metal itself is setup to run unit tests on Clang 3.9 on Travis CI [1], but unfortunately that version of Clang is still not supported on their recommended container-based images [2]. For that same reason we are currently unable to publish benchmark data for Clang 3.9 compiler on metaben.ch.
Regarding GCC, Metal is in fact tested on version 6.2 on Travis [3], but due to some recent changing in the versioning scheme of GCC, Ubuntu abolished the minor version from their packaging of GCC, which means GCC 6 translates to the latest minor release, currently 6.2. Likewise GCC 5 currently translates to 5.4. The same goes for benchmark results published on metaben.ch.
My point really is that whatever Travis CI or any other CI supports you yourself should test on your local computer using the latest version of compilers which will support better the level of C++ compliance you need.
I also noticed that Travis CI uses old versions of both clang and gcc, so I wonder why so much software is still using old versions when new, better ones are available, especially as relates to C++11 on up support.
I believe Travis CI provides the original versions of development tools that are available by default on the OS images they use. Since their recommended container-based environment still runs on Ubuntu 12.04, one can imagine that the versions of GCC and Clang available there are pretty ancient by now. One can always install more recent versions of compilers from some selected external sources, but that must go through a process of whitelisting, which unfortunately takes much too long sometimes.
I think that is why CI cannot be the only method of testing libraries. While I find Travis CI useful the fact that CI services may be well behind the curve as far as the latest testing environments means that local testing is still very important. This is especially true for C++11 on up implementations which may well need the latest versions of compilers to certify that their use of the latest features of C++ work correctly. Even if someone were to write a C++ library which needs only basic C++03 compliance to work properly I think he would still want to promote the library as working on the latest versions of popular compilers ( gcc, clang, VC++ ) rather than much older releases.
[1]: https://github.com/brunocodutra/metal/blob/master/.travis.yml#L83 [2]: https://github.com/travis-ci/apt-source-whitelist/issues/300 [3]: https://travis-ci.org/brunocodutra/metal/jobs/166841250#L563
On Sun, Nov 13, 2016 at 9:34 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 11/13/2016 7:22 AM, Bruno Dutra wrote:
I believe Travis CI provides the original versions of development tools that are available by default on the OS images they use. Since their recommended container-based environment still runs on Ubuntu 12.04, one can imagine that the versions of GCC and Clang available there are pretty ancient by now. One can always install more recent versions of compilers from some selected external sources, but that must go through a process of whitelisting, which unfortunately takes much too long sometimes.
I think that is why CI cannot be the only method of testing libraries. While I find Travis CI useful the fact that CI services may be well behind the curve as far as the latest testing environments means that local testing is still very important. This is especially true for C++11 on up implementations which may well need the latest versions of compilers to certify that their use of the latest features of C++ work correctly.
For Travis you can choose to use Trusty, ie Ubuntu 14. And you can use it in non-container mode. And you can turn on sudo support. And hence can install whatever you like from sources or packages. Which is what Predef does for testing the almost dozen compiler versions on Travis. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Sun, Nov 13, 2016 at 3:42 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Sun, Nov 13, 2016 at 9:34 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 11/13/2016 7:22 AM, Bruno Dutra wrote:
I believe Travis CI provides the original versions of development tools that are available by default on the OS images they use. Since their recommended container-based environment still runs on Ubuntu 12.04, one can imagine that the versions of GCC and Clang available there are pretty ancient by now. One can always install more recent versions of compilers from some selected external sources, but that must go through a process of whitelisting, which unfortunately takes much too long sometimes.
I think that is why CI cannot be the only method of testing libraries. While I find Travis CI useful the fact that CI services may be well behind the curve as far as the latest testing environments means that local testing is still very important. This is especially true for C++11 on up implementations which may well need the latest versions of compilers to certify that their use of the latest features of C++ work correctly.
For Travis you can choose to use Trusty, ie Ubuntu 14. And you can use it in non-container mode. And you can turn on sudo support. And hence can install whatever you like from sources or packages. Which is what Predef does for testing the almost dozen compiler versions on Travis.
Well noted. I've been refraining from migrating to Trusty, because it is claimed to be slower than the container based precise machines and also because their whitelisting system did work up until recently well enough not to bother me much, but to be frank enough is enough of waiting for clang-3.9, I guess it's time to move on [1]. Unfortunately it won't be that easy for metaben.ch, because some jobs often take longer than the maximum 50 min even on the faster container based environment, so migrating to Trusty images would only make it worse. [1]: https://github.com/brunocodutra/metal/issues/50
Bruno Dutra wrote:
Well noted. I've been refraining from migrating to Trusty, because it is claimed to be slower than the container based precise machines and also because their whitelisting system did work up until recently well enough not to bother me much, but to be frank enough is enough of waiting for clang-3.9, I guess it's time to move on [1].
You can use Trusty with sudo: false now. https://blog.travis-ci.com/2016-11-08-trusty-container-public-beta/
On Sun, Nov 13, 2016 at 6:02 PM, Peter Dimov <lists@pdimov.com> wrote:
Bruno Dutra wrote:
Well noted. I've been refraining from migrating to Trusty, because it is
claimed to be slower than the container based precise machines and also because their whitelisting system did work up until recently well enough not to bother me much, but to be frank enough is enough of waiting for clang-3.9, I guess it's time to move on [1].
You can use Trusty with sudo: false now.
https://blog.travis-ci.com/2016-11-08-trusty-container-public-beta/
That's excellent news! Currently it appears neither Clang nor recent GCC are whitelisted [1], but hopefully it won't take that long for them to be whitelisted on Trusty. [1]: https://github.com/travis-ci/apt-package-whitelist/blob/master/ubuntu-trusty Regards, Bruno
On 11/13/2016 9:42 AM, Rene Rivera wrote:
On Sun, Nov 13, 2016 at 9:34 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 11/13/2016 7:22 AM, Bruno Dutra wrote:
I believe Travis CI provides the original versions of development tools that are available by default on the OS images they use. Since their recommended container-based environment still runs on Ubuntu 12.04, one can imagine that the versions of GCC and Clang available there are pretty ancient by now. One can always install more recent versions of compilers from some selected external sources, but that must go through a process of whitelisting, which unfortunately takes much too long sometimes.
I think that is why CI cannot be the only method of testing libraries. While I find Travis CI useful the fact that CI services may be well behind the curve as far as the latest testing environments means that local testing is still very important. This is especially true for C++11 on up implementations which may well need the latest versions of compilers to certify that their use of the latest features of C++ work correctly.
For Travis you can choose to use Trusty, ie Ubuntu 14. And you can use it in non-container mode. And you can turn on sudo support. And hence can install whatever you like from sources or packages. Which is what Predef does for testing the almost dozen compiler versions on Travis.
Where is there information on Travis CI about which compiler versions are available and how you change the .travis.yml file to specify one of those versions ?
On Sun, Nov 13, 2016 at 3:34 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 11/13/2016 7:22 AM, Bruno Dutra wrote:
On Sun, Nov 13, 2016 at 6:47 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 11/12/2016 5:26 PM, Bruno Dutra wrote:
On Mon, Feb 29, 2016 at 1:52 PM, Bruno Dutra <brunocodutra@gmail.com>
[snip]
2016-02-29 6:37 GMT-03:00, Jens Weller <JensWeller@gmx.de>:
[snip]
Do you compile as fast as Brigand?
My next efforts will be directed toward developing a framework for running benchmarks. I'll be sure to add Brigand, as well as other alternatives of which I am aware, for comparison purposes.
[snip]
Now, finally, back to the question: Yes, Metal compiles just as fast as Brigand on both Clang and GCC and even considerably faster for some algorithms [1].
I should also mention that meanwhile I have completely overhauled Metal a few too many times already to make sure I explored all the possibilities modern C++ offers TMP and even though it's still subject to some minor refactoring, I'm confident that its current API is close to what will eventually make it to a stable release. In fact I've already written most of the reference documentation as I don't expect it to change significantly anymore and as such I'd like to invite all of those interested in metaprogramming to take a look at it [2]. Any feedback will be greatly appreciated.
[1]: http://metaben.ch/ [2]: http://brunocodutra.github.io/metal/
A quick note. Since the latest released clang version is 3.9 and the latest released gcc version is 6.2, wouldn't it be better if metal was tested with these versions.
Metal itself is setup to run unit tests on Clang 3.9 on Travis CI [1], but unfortunately that version of Clang is still not supported on their recommended container-based images [2]. For that same reason we are currently unable to publish benchmark data for Clang 3.9 compiler on metaben.ch.
Regarding GCC, Metal is in fact tested on version 6.2 on Travis [3], but due to some recent changing in the versioning scheme of GCC, Ubuntu abolished the minor version from their packaging of GCC, which means GCC 6 translates to the latest minor release, currently 6.2. Likewise GCC 5 currently translates to 5.4. The same goes for benchmark results published on metaben.ch.
My point really is that whatever Travis CI or any other CI supports you yourself should test on your local computer using the latest version of compilers which will support better the level of C++ compliance you need.
Yes absolutely, in fact I use the development branches of these compilers on my machine, while using Travis and Appveyor to check the minimum required versions. I also noticed that Travis CI uses old versions of both clang and gcc, so
I wonder why so much software is still using old versions when new, better ones are available, especially as relates to C++11 on up support.
I believe Travis CI provides the original versions of development tools that are available by default on the OS images they use. Since their recommended container-based environment still runs on Ubuntu 12.04, one can imagine that the versions of GCC and Clang available there are pretty ancient by now. One can always install more recent versions of compilers from some selected external sources, but that must go through a process of whitelisting, which unfortunately takes much too long sometimes.
I think that is why CI cannot be the only method of testing libraries. While I find Travis CI useful the fact that CI services may be well behind the curve as far as the latest testing environments means that local testing is still very important. This is especially true for C++11 on up implementations which may well need the latest versions of compilers to certify that their use of the latest features of C++ work correctly.
Even if someone were to write a C++ library which needs only basic C++03 compliance to work properly I think he would still want to promote the library as working on the latest versions of popular compilers ( gcc, clang, VC++ ) rather than much older releases.
I suppose you refer to the compatibility status table [1]? Do you think it would be better not to mention the exact minimum versions that are tested and known to work with Metal? [1]: http://brunocodutra.github.io/metal/#status Regards, Bruno
On 11/13/2016 11:40 AM, Bruno Dutra wrote:
On Sun, Nov 13, 2016 at 3:34 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 11/13/2016 7:22 AM, Bruno Dutra wrote:
On Sun, Nov 13, 2016 at 6:47 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 11/12/2016 5:26 PM, Bruno Dutra wrote:
On Mon, Feb 29, 2016 at 1:52 PM, Bruno Dutra <brunocodutra@gmail.com>
[snip]
2016-02-29 6:37 GMT-03:00, Jens Weller <JensWeller@gmx.de>:
[snip] > Do you compile as fast as Brigand? > > My next efforts will be directed toward developing a framework for running benchmarks. I'll be sure to add Brigand, as well as other alternatives of which I am aware, for comparison purposes.
[snip]
Now, finally, back to the question: Yes, Metal compiles just as fast as Brigand on both Clang and GCC and even considerably faster for some algorithms [1].
I should also mention that meanwhile I have completely overhauled Metal a few too many times already to make sure I explored all the possibilities modern C++ offers TMP and even though it's still subject to some minor refactoring, I'm confident that its current API is close to what will eventually make it to a stable release. In fact I've already written most of the reference documentation as I don't expect it to change significantly anymore and as such I'd like to invite all of those interested in metaprogramming to take a look at it [2]. Any feedback will be greatly appreciated.
[1]: http://metaben.ch/ [2]: http://brunocodutra.github.io/metal/
A quick note. Since the latest released clang version is 3.9 and the latest released gcc version is 6.2, wouldn't it be better if metal was tested with these versions.
Metal itself is setup to run unit tests on Clang 3.9 on Travis CI [1], but unfortunately that version of Clang is still not supported on their recommended container-based images [2]. For that same reason we are currently unable to publish benchmark data for Clang 3.9 compiler on metaben.ch.
Regarding GCC, Metal is in fact tested on version 6.2 on Travis [3], but due to some recent changing in the versioning scheme of GCC, Ubuntu abolished the minor version from their packaging of GCC, which means GCC 6 translates to the latest minor release, currently 6.2. Likewise GCC 5 currently translates to 5.4. The same goes for benchmark results published on metaben.ch.
My point really is that whatever Travis CI or any other CI supports you yourself should test on your local computer using the latest version of compilers which will support better the level of C++ compliance you need.
Yes absolutely, in fact I use the development branches of these compilers on my machine, while using Travis and Appveyor to check the minimum required versions.
I also noticed that Travis CI uses old versions of both clang and gcc, so
I wonder why so much software is still using old versions when new, better ones are available, especially as relates to C++11 on up support.
I believe Travis CI provides the original versions of development tools that are available by default on the OS images they use. Since their recommended container-based environment still runs on Ubuntu 12.04, one can imagine that the versions of GCC and Clang available there are pretty ancient by now. One can always install more recent versions of compilers from some selected external sources, but that must go through a process of whitelisting, which unfortunately takes much too long sometimes.
I think that is why CI cannot be the only method of testing libraries. While I find Travis CI useful the fact that CI services may be well behind the curve as far as the latest testing environments means that local testing is still very important. This is especially true for C++11 on up implementations which may well need the latest versions of compilers to certify that their use of the latest features of C++ work correctly.
Even if someone were to write a C++ library which needs only basic C++03 compliance to work properly I think he would still want to promote the library as working on the latest versions of popular compilers ( gcc, clang, VC++ ) rather than much older releases.
I suppose you refer to the compatibility status table [1]? Do you think it would be better not to mention the exact minimum versions that are tested and known to work with Metal?
I think it would be better to list all the versions that you have tested and which you know are working properly. I don't mind minimum versions but I did not understand from it that you are implying that all later versions have been tested and should work with Metal.
[1]: http://brunocodutra.github.io/metal/#status
Regards, Bruno
On Mon, Nov 14, 2016 at 12:06 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 11/13/2016 11:40 AM, Bruno Dutra wrote:
On Sun, Nov 13, 2016 at 3:34 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
[snip]
Even if someone were to write a C++ library which needs only basic C++03 compliance to work properly I think he would still want to promote the library as working on the latest versions of popular compilers ( gcc, clang, VC++ ) rather than much older releases.
I suppose you refer to the compatibility status table [1]? Do you think it would be better not to mention the exact minimum versions that are tested and known to work with Metal?
I think it would be better to list all the versions that you have tested and which you know are working properly. I don't mind minimum versions but I did not understand from it that you are implying that all later versions have been tested and should work with Metal.
Thanks for your feedback, I'll be sure to make it explicit from the User Manual that Metal is tested on newer compiler versions as well [1]. On Sun, Nov 13, 2016 at 11:52 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 11/13/2016 9:42 AM, Rene Rivera wrote:
For Travis you can choose to use Trusty, ie Ubuntu 14. And you can use it in non-container mode. And you can turn on sudo support. And hence can install whatever you like from sources or packages. Which is what Predef does for testing the almost dozen compiler versions on Travis.
Where is there information on Travis CI about which compiler versions are available
I think in the particular case of C++ on Travis CI it is kind of implicit that you should take care of installing whatever development tools fit your needs. To make this easy for the developer, they make it possible for the user to specify 'sudo: required', which basically provides easy access to the various package repositories available to Ubuntu. Alternatively, the user can give up on administrator rights in exchange for better hardware and faster builds, but in this case one must request repositories and packages to be whitelisted by the Travis team [2], [3], [4], which is often inconvenient.
and how you change the .travis.yml file to specify one of those versions ?
For an example of how to set up Travis to test on several versions of GCC and Clang, you can take a look at Metal's '.travis.yml' [5], although there are plenty of other good examples out there, for instance you can also check Boost.Hana and Metabench. [1]: https://github.com/brunocodutra/metal/issues/51 [2]: https://github.com/travis-ci/apt-source-whitelist [3]: https://github.com/travis-ci/apt-package-whitelist/blob/master/ubuntu-trusty [4]: https://github.com/travis-ci/apt-package-whitelist/blob/master/ubuntu-precis... [5]: https://github.com/brunocodutra/metal/blob/master/.travis.yml Regards, Bruno
Bruno Dutra wrote:
On Mon, Nov 14, 2016 at 12:06 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
and how you change the .travis.yml file to specify one of those versions ?
For an example of how to set up Travis to test on several versions of GCC and Clang, you can take a look at Metal's '.travis.yml' [5], ...
I used Bruno's .travis.yml as a starting point to create a minimal Travis configuration with a build matrix that covers several combination of g++/clang++ versions and -std settings, and you can see the result here: https://github.com/pdimov/mp11/blob/develop/.travis.yml I omitted clang-3.5 as it conflicts with the other three, and clang-3.9 as it doesn't seem to exist as a package. For a C++03 library such as iostreams, you should probably include C++03 tests as well, and test the compiler versions installed by default, by adding f.ex. - os: linux env: TOOLSET=gcc COMPILER=g++ CXXSTD=c++03 - os: linux env: TOOLSET=clang COMPILER=clang++ CXXSTD=c++03 - os: osx env: TOOLSET=clang COMPILER=clang++ CXXSTD=c++03 and you might also want to cut down on the C++14/C++1z tests, according to taste. The Linux tests are quick and generally run in parallel, but the OS X ones are slower. You could also add g++ 4.7 and 4.8 if you feel like it (the default at the moment is 4.6 if I'm not mistaken.)
On Tue, Nov 15, 2016 at 10:41 PM, Peter Dimov <lists@pdimov.com> wrote:
Bruno Dutra wrote:
On Mon, Nov 14, 2016 at 12:06 AM, Edward Diener <eldiener@tropicsoft.com>
wrote:
and how you change the .travis.yml file to specify one of those versions
?
For an example of how to set up Travis to test on several versions of GCC and Clang, you can take a look at Metal's '.travis.yml' [5], ...
I used Bruno's .travis.yml as a starting point to create a minimal Travis configuration with a build matrix that covers several combination of g++/clang++ versions and -std settings, and you can see the result here:
https://github.com/pdimov/mp11/blob/develop/.travis.yml
I omitted clang-3.5 as it conflicts with the other three, and clang-3.9 as it doesn't seem to exist as a package.
Meanwhile, following Rene's suggestion to move away from Travis' container based infrastructure, I was also able to run tests on Clang 3.9 and even on what seems to be nightly snapshots of Clang 4.0: https://github.com/brunocodutra/metal/blob/develop/.travis.yml. BTW, have you considered adding mp11 to metaben.ch, Peter? It has been suggested before: https://github.com/ldionne/metabench/issues/136 Regards, Bruno
Bruno Dutra wrote:
Meanwhile, following Rene's suggestion to move away from Travis' container based infrastructure, I was also able to run tests on Clang 3.9 and even on what seems to be nightly snapshots of Clang 4.0:
https://github.com/brunocodutra/metal/blob/develop/.travis.yml.
I don't care that much for 3.9 and 4.0, but the -stdlib=libc++ option is intriguing. Does it require sudo?
BTW, have you considered adding mp11 to metaben.ch, Peter? It has been suggested before: https://github.com/ldionne/metabench/issues/136
I haven't, this is the first time I hear of the possibility. I doubt that I'll have time for that at the moment; CMake and Ruby aren't my strong suits.
On 11/15/2016 4:56 PM, Peter Dimov wrote:
Bruno Dutra wrote:
Meanwhile, following Rene's suggestion to move away from Travis' container based infrastructure, I was also able to run tests on Clang 3.9 and even on what seems to be nightly snapshots of Clang 4.0:
https://github.com/brunocodutra/metal/blob/develop/.travis.yml.
I don't care that much for 3.9 and 4.0, but the -stdlib=libc++ option is intriguing. Does it require sudo?
BTW, have you considered adding mp11 to metaben.ch, Peter? It has been suggested before: https://github.com/ldionne/metabench/issues/136
I haven't, this is the first time I hear of the possibility. I doubt that I'll have time for that at the moment; CMake and Ruby aren't my strong suits.
Speaking of mp11... MP11 works on VS2015 while Hana and Meta don't which makes them unusable for me and a large group of users. Does Metal support VS2015?
On Nov 16, 2016 00:35, "Michael Marcin" <mike.marcin@gmail.com> wrote:
On 11/15/2016 4:56 PM, Peter Dimov wrote:
Bruno Dutra wrote:
Meanwhile, following Rene's suggestion to move away from Travis' container based infrastructure, I was also able to run tests on Clang 3.9 and even on what seems to be nightly snapshots of Clang 4.0:
https://github.com/brunocodutra/metal/blob/develop/.travis.yml.
I don't care that much for 3.9 and 4.0, but the -stdlib=libc++ option is intriguing. Does it require sudo?
BTW, have you considered adding mp11 to metaben.ch, Peter? It has been suggested before: https://github.com/ldionne/metabench/issues/136
I haven't, this is the first time I hear of the possibility. I doubt that I'll have time for that at the moment; CMake and Ruby aren't my strong suits.
Speaking of mp11...
MP11 works on VS2015 while Hana and Meta don't which makes them unusable
for me and a large group of users.
Does Metal support VS2015?
Yes it does [1], and I can't stress enough the enormous amount of time I've spent thus far making sure it did. [1] http://brunocodutra.github.io/metal/#status
On 11/15/2016 4:41 PM, Peter Dimov wrote:
Bruno Dutra wrote:
On Mon, Nov 14, 2016 at 12:06 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
and how you change the .travis.yml file to specify one of those versions > ?
For an example of how to set up Travis to test on several versions of GCC and Clang, you can take a look at Metal's '.travis.yml' [5], ...
I used Bruno's .travis.yml as a starting point to create a minimal Travis configuration with a build matrix that covers several combination of g++/clang++ versions and -std settings, and you can see the result here:
This is very much appreciated but I find Travis CI just confusing in the difficulty of specifying what compilers/versions should be run on which OSs, and what is actually available to test. I can of course try to work with the travis.yml in the link above. There are now your .travis.yml, Bruno's .travis.yml based on your original solution using boostdep, and Rene's solution. I appreciate everything everyone has done but I feel I will be spending too much time on a product ( Travis CI ) for which I understand little, which is difficult to use, and whose documentation is appalling. I just have better things to do ( like programming <g> ) than to joust with Travis CI. I understand of course that is is "free" but I don't see it as a good solution to continuous testing.
I omitted clang-3.5 as it conflicts with the other three, and clang-3.9 as it doesn't seem to exist as a package.
For a C++03 library such as iostreams, you should probably include C++03 tests as well, and test the compiler versions installed by default, by adding f.ex.
- os: linux env: TOOLSET=gcc COMPILER=g++ CXXSTD=c++03
- os: linux env: TOOLSET=clang COMPILER=clang++ CXXSTD=c++03
- os: osx env: TOOLSET=clang COMPILER=clang++ CXXSTD=c++03
and you might also want to cut down on the C++14/C++1z tests, according to taste. The Linux tests are quick and generally run in parallel, but the OS X ones are slower.
You could also add g++ 4.7 and 4.8 if you feel like it (the default at the moment is 4.6 if I'm not mistaken.)
Bruno Dutra wrote:
I expected assemble_number to apply a fold using bx+y instead of raising b to powers.
On Sun, Nov 13, 2016 at 12:22 PM, Peter Dimov <lists@pdimov.com> wrote:
Bruno Dutra wrote:
[2]: http://brunocodutra.github.io/metal/
I expected assemble_number to apply a fold using bx+y instead of raising b to powers.
Excellent suggestion, logged here: https://github.com/brunocodutra/metal/issues/49
On Sunday, February 28, 2016 at 5:17:49 PM UTC-6, Bruno Dutra wrote:
Dear Community,
About a year ago today, there was a proliferation of threads [1][2][3] in this mailing list concerning the future of Boost.MPL, or even whether it had a future at all, and opinions diverged widely on the matter. Many have expressed concerns about the fact Boost.MPL was long outdated and proposed major changes to open path for modernization, while some others argued against it, fearing unexpected and disastrous side-effects could propagate throughout the rest of Boost. A few questioned if it was worth it at all to spend any further resources on Boost.MPL given the fact new alternatives were coming up, such as Boost.Hana, which departed entirely from template metaprogramming, yet some argued TMP remained a competitive alternative for type computations in C++14 as it has been demonstrated by Peter Dimov in his impressive articles [4] on modern TMP.
Amidst all this, a proposal by Robert Ramey [5] caught my attention and inspired me to develop what I call Metal [6], a template metaprogramming library designed on the same core principles as Boost.MPL, but written from the very beginning to take full advantage of C++11. Metal was not designed to be a strict drop in replacement for Boost.MPL though, it was rather meant to be regarded as a modern version of Boost.MPL's original API, diverging only where it could really benefit from modern C++ and that essentially means gains of several orders of magnitude in performance** and lower memory consumption. At this point Metal is very close to where I originally intended to bring it and I think it's time I gauge interest from the community on a modest proposal I've been maturing along the past year.
As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead.
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them.
This proposal also overcomes the problem of dealing with the maintainability of Boost.MPL, since it provides a way for smooth transition from legacy hacks required by ancient compilers into a cleaner and easier to maintain C++11 codebase, besides avoiding any breaking changes within existing code in the process. Furthermore, should this proposal make it into Boost, I would be naturally willing to take responsibility for the maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for quite some time now, often with limited resources.
Comparing Metal and Boost.MPL there are a few noteworthy differences. Metafunction Classes have proven themselves entirely unnecessary and have thus been removed altogether in favour of pure Lambdas (in the Boost.MPL sense). Moreover, iterators make little sense in a functional world, so these too have been removed despite the fact they may easily be emulated in the new design. Moreover Metal develops the concept of optionals, that is, its metafunctions only have a nested ::type defined when they may be successfully computed, what may be safely tested using metal::is_just and may also be used to SFINAE out of miscomputations.
Finally I'd like to point out that Metal was designed to be portable across as many compilers as possible and three of the most popular ones are continuously tested using Travis and Appveyor: Clang 3.5+, GCC 4.8+ and MSVC 14 (2015).
I hope this is a reasonable proposal and I look forward into your opinions about it.
** Even though I haven't published any benchmarks yet, an example follows just to back my claims regarding performance (just tested on my personal laptop running linux):
//Generate a list containing 10 thousand instances of std::integral_constant, from 0 to 9999 using l = metal::enumerate_t<metal::integer<10000>>;
// GCC 5.3 ~0.4 s // Clang 3.7 ~0.5 s
//Transform a list containing 5 thousand numbers by squaring each element using l1 = metal::enumerate_t<metal::number<long long, 5000>>; using l2 = metal::transform_t<metal::pow<metal::_1, metal::integer<2>>, l1>;
// GCC 5.3 ~5.6 s // Clang 3.7 ~3.0 s
That looks pretty nice. For my libraries, however, I support back to gcc 4.6, so I wouldn't be able to use them. At least between the two libraries that I have the common metaprogramming constructs they share are: - Integral constant defined with all the operators - Integer sequences - Fast and_ and or_ metafunctions - Macros to handle template aliases - Macros to handle type trait intrinsics - Macros to handle fold expressions over booleans I believe Hana has some similar constructs as well. So, I believe these constructs could be useful across many libraries. I don't where would be the right place to put these common utilities. Also, in the Tick library it uses more metaprogramming utilities, such as placeholder expressions and `set`, which I could replace with your library if it supported to gcc 4.6. I could help with the effort to add support for gcc 4.6 if you found it acceptable. Paul
[1]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257680 [2]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257983 [3]: http://thread.gmane.org/gmane.comp.lib.boost.devel/258843 [4]: http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [5]: http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/ [6]: http://brunocodutra.github.io/metal/ <http://www.google.com/url?q=http%3A%2F%2Fbrunocodutra.github.io%2Fmetal%2F&sa=D&sntz=1&usg=AFQjCNEkw1UXe-eT03tiTWfyGNSnDCM0ow>
Regards, Bruno Dutra
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead.
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them.
I do not think you should focus too much on Boost.MPL. Boost.MPL is C++ 03 metaprogramming library. If you need a C++11/14/17 TMP, then you need another library. In Brigand we looked at Boost.MPL in terms of features, like, you should be able to do everything you do with Boost.MPL with Brigand, but we didn't look at *how* it's done with Boost.MPL, because it doesn't matter. C++ 11 is a different language than C++ 03. It would be like writing a C++ 11 Json library and bothering about how it's been implemented in Python. If you want to change a single line of Boost.MPL or add a wrapper you will spend a lot of time in back testing and will never be 100% sure it's retro-compatible. A lot of critical code, out there, depends on Boost.MPL and I don't think it's a good thing to add friction in the upgrade path. I also submit that Boost library authors currently using Boost.MPL will go after you with pitchforks if you break anything. Having a proxy that switches backend transparently looks like a good idea but is, in my opinion, very hard to do for little to no benefit. You might be surprised to learn than in real-life project switching from Boost.MPL to a faster "more modern" MPL doesn't yield any speed improvement unless you change the way your use that MPL. I am speaking from experience because when we switched from Boost.MPL to Brigand in quasardb, we had to change a certain number of things to see any impact in terms of compilation speed. Whereas if you compile side by side a Boost.MPL program and a Brigand program there is easily one order of magnitude in speed gain with Brigand. I think if people want to do C++ 11/14/17 TMP they might as well start with new principles and I don't think it's worth annoying Boost.MPL users with evolution that, in the end, might not be as substantial as you infer. The other advantage of not extending/modifying Boost.MPL is that nothing prevents you to progressively switch from one library to the other. For example, progressively migrate the code from Boost.MPL to Boost.Hana. This is of course not an opinion on the quality of your Metal library, just a comment on its relation with Boost.MPL. Kind regards. --Edouard
2016-03-01 12:36 GMT-03:00, edouard@fausse.info <edouard@fausse.info>:
As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead.
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them.
I do not think you should focus too much on Boost.MPL. Boost.MPL is C++ 03 metaprogramming library. If you need a C++11/14/17 TMP, then you need another library.
In Brigand we looked at Boost.MPL in terms of features, like, you should be able to do everything you do with Boost.MPL with Brigand, but we didn't look at *how* it's done with Boost.MPL, because it doesn't matter. C++ 11 is a different language than C++ 03. It would be like writing a C++ 11 Json library and bothering about how it's been implemented in Python.
I believe we concur then. I should stress that Metal is an entirely new TMP library written from scratch to take advantage of everything C++11 has to offer, no restrictions imposed. Metal’s only relation to Boost.MPL is the fact it has been designed so as to _ look_ very much like Boost.MPL from the point of view of the user, that is, it is built around similar concepts and provides roughly the same metafunctions, so, in this sense, I argue it is a natural successor to Boost.MPL.
If you want to change a single line of Boost.MPL or add a wrapper you will spend a lot of time in back testing and will never be 100% sure it's retro-compatible. A lot of critical code, out there, depends on Boost.MPL and I don't think it's a good thing to add friction in the upgrade path. I also submit that Boost library authors currently using Boost.MPL will go after you with pitchforks if you break anything.
Having a proxy that switches backend transparently looks like a good idea but is, in my opinion, very hard to do for little to no benefit.
I very much share your concern. It poses a considerable risk to inpact in any way a core library such as Boost.MPL that has been in use for over a decade now and that is why I turn to the community for discussing this proposal. I do believe it is possible to make sure the alternative implementation of Boost.MPL honours every requirement of its documentation with reasonable confidence, since it is easier for a pure functional language, but it is also possible that some code out there still breaks due to their reliance on undocumented behaviour (been there done that). Now should Boost care for such cases?
You might be surprised to learn than in real-life project switching from Boost.MPL to a faster "more modern" MPL doesn't yield any speed improvement unless you change the way your use that MPL. I am speaking from experience because when we switched from Boost.MPL to Brigand in quasardb, we had to change a certain number of things to see any impact in terms of compilation speed. Whereas if you compile side by side a Boost.MPL program and a Brigand program there is easily one order of magnitude in speed gain with Brigand.
That is not true in general, for it depends on how Boost.MPL is used. More specifically, if sequences are explicitly folded, iterators are explicitly tracked or any other mandatorily recursive algorithm is used, then I agree with you that using Metal as a backend for Boost.MPL would only bring marginal improvements at most. However, if mostly algorithms that may be somehow expressed in terms of variadic template expansion are used, such as transform, find, remove, replace, contains, partition, etc., then most surely dramatic improvements would be perceived. Since you mentioned performance, I would like to clarify that Metal was not designed to be the fastest TMP library out there, nor it is advertised as such, rather I pose that it is just fast enough for mainstream metaprogramming and that’s already a couple of orders of magnitude faster than Boost.MPL in most cases. That means I actively avoided such optimizations as fast tracked recursion and unrolling, which tend to demand additional template specializations, which clutter the code base and thus impair clarity and maintenance. My goals were instead make sure Metal was as easy as possible to maintain and that is why I believe it is a good fit for Boost. I invite you and everyone else to briefly browse through the source code [1], so you can see I did try hard to keep it simple and easy to understand.
I think if people want to do C++ 11/14/17 TMP they might as well start with new principles and I don't think it's worth annoying Boost.MPL users with evolution that, in the end, might not be as substantial as you infer.
The other advantage of not extending/modifying Boost.MPL is that nothing prevents you to progressively switch from one library to the other. For example, progressively migrate the code from Boost.MPL to Boost.Hana.
I designed Metal around the concept of TMP because I do believe it is expressive and cleaner when all one needs to do is manipulate some types, express a few concepts and trigger SFINAE accordingly. In other words, I consider TMP a feature, not a constraint.
This is of course not an opinion on the quality of your Metal library, just a comment on its relation with Boost.MPL.
I appreciate your comments and I hope I could clarify a few aspects regarding the design of Metal. [1]: https://github.com/brunocodutra/metal/tree/master/include/metal -- Bruno Dutra
On 3/2/2016 12:23 PM, Bruno Dutra wrote:
2016-03-01 12:36 GMT-03:00, edouard@fausse.info <edouard@fausse.info>:
As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead.
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them.
I do not think you should focus too much on Boost.MPL. Boost.MPL is C++ 03 metaprogramming library. If you need a C++11/14/17 TMP, then you need another library.
In Brigand we looked at Boost.MPL in terms of features, like, you should be able to do everything you do with Boost.MPL with Brigand, but we didn't look at *how* it's done with Boost.MPL, because it doesn't matter. C++ 11 is a different language than C++ 03. It would be like writing a C++ 11 Json library and bothering about how it's been implemented in Python.
I believe we concur then. I should stress that Metal is an entirely new TMP library written from scratch to take advantage of everything C++11 has to offer, no restrictions imposed.
Metal’s only relation to Boost.MPL is the fact it has been designed so as to _ look_ very much like Boost.MPL from the point of view of the user, that is, it is built around similar concepts and provides roughly the same metafunctions, so, in this sense, I argue it is a natural successor to Boost.MPL.
If you want to change a single line of Boost.MPL or add a wrapper you will spend a lot of time in back testing and will never be 100% sure it's retro-compatible. A lot of critical code, out there, depends on Boost.MPL and I don't think it's a good thing to add friction in the upgrade path. I also submit that Boost library authors currently using Boost.MPL will go after you with pitchforks if you break anything.
Having a proxy that switches backend transparently looks like a good idea but is, in my opinion, very hard to do for little to no benefit.
I very much share your concern. It poses a considerable risk to inpact in any way a core library such as Boost.MPL that has been in use for over a decade now and that is why I turn to the community for discussing this proposal.
I do believe it is possible to make sure the alternative implementation of Boost.MPL honours every requirement of its documentation with reasonable confidence, since it is easier for a pure functional language, but it is also possible that some code out there still breaks due to their reliance on undocumented behaviour (been there done that). Now should Boost care for such cases?
No. Any code using undocumented parts of a Boost library, or undocumented behavior which just happens to work with some release of some Boost library, is on its own. That can't be the concern of a library developer IMO. However the responder has a good point that you need to be thorough in testing any change to Boost.MPL since it is such a core library of Boost. If you need help in testing MPL in an environment which may be difficult for you to replicate don't be afrad to ask on this mailing list.
You might be surprised to learn than in real-life project switching from Boost.MPL to a faster "more modern" MPL doesn't yield any speed improvement unless you change the way your use that MPL. I am speaking from experience because when we switched from Boost.MPL to Brigand in quasardb, we had to change a certain number of things to see any impact in terms of compilation speed. Whereas if you compile side by side a Boost.MPL program and a Brigand program there is easily one order of magnitude in speed gain with Brigand.
That is not true in general, for it depends on how Boost.MPL is used.
More specifically, if sequences are explicitly folded, iterators are explicitly tracked or any other mandatorily recursive algorithm is used, then I agree with you that using Metal as a backend for Boost.MPL would only bring marginal improvements at most.
However, if mostly algorithms that may be somehow expressed in terms of variadic template expansion are used, such as transform, find, remove, replace, contains, partition, etc., then most surely dramatic improvements would be perceived.
Since you mentioned performance, I would like to clarify that Metal was not designed to be the fastest TMP library out there, nor it is advertised as such, rather I pose that it is just fast enough for mainstream metaprogramming and that’s already a couple of orders of magnitude faster than Boost.MPL in most cases. That means I actively avoided such optimizations as fast tracked recursion and unrolling, which tend to demand additional template specializations, which clutter the code base and thus impair clarity and maintenance. My goals were instead make sure Metal was as easy as possible to maintain and that is why I believe it is a good fit for Boost. I invite you and everyone else to briefly browse through the source code [1], so you can see I did try hard to keep it simple and easy to understand.
I think if people want to do C++ 11/14/17 TMP they might as well start with new principles and I don't think it's worth annoying Boost.MPL users with evolution that, in the end, might not be as substantial as you infer.
The other advantage of not extending/modifying Boost.MPL is that nothing prevents you to progressively switch from one library to the other. For example, progressively migrate the code from Boost.MPL to Boost.Hana.
I designed Metal around the concept of TMP because I do believe it is expressive and cleaner when all one needs to do is manipulate some types, express a few concepts and trigger SFINAE accordingly. In other words, I consider TMP a feature, not a constraint.
This is of course not an opinion on the quality of your Metal library, just a comment on its relation with Boost.MPL.
I appreciate your comments and I hope I could clarify a few aspects regarding the design of Metal.
[1]: https://github.com/brunocodutra/metal/tree/master/include/metal
2016-03-02 15:03 GMT-03:00, Edward Diener <eldiener@tropicsoft.com>:
On 3/2/2016 12:23 PM, Bruno Dutra wrote:
2016-03-01 12:36 GMT-03:00, edouard@fausse.info <edouard@fausse.info>:
As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead.
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them.
I do not think you should focus too much on Boost.MPL. Boost.MPL is C++ 03 metaprogramming library. If you need a C++11/14/17 TMP, then you need another library.
In Brigand we looked at Boost.MPL in terms of features, like, you should be able to do everything you do with Boost.MPL with Brigand, but we didn't look at *how* it's done with Boost.MPL, because it doesn't matter. C++ 11 is a different language than C++ 03. It would be like writing a C++ 11 Json library and bothering about how it's been implemented in Python.
I believe we concur then. I should stress that Metal is an entirely new TMP library written from scratch to take advantage of everything C++11 has to offer, no restrictions imposed.
Metal’s only relation to Boost.MPL is the fact it has been designed so as to _ look_ very much like Boost.MPL from the point of view of the user, that is, it is built around similar concepts and provides roughly the same metafunctions, so, in this sense, I argue it is a natural successor to Boost.MPL.
If you want to change a single line of Boost.MPL or add a wrapper you will spend a lot of time in back testing and will never be 100% sure it's retro-compatible. A lot of critical code, out there, depends on Boost.MPL and I don't think it's a good thing to add friction in the upgrade path. I also submit that Boost library authors currently using Boost.MPL will go after you with pitchforks if you break anything.
Having a proxy that switches backend transparently looks like a good idea but is, in my opinion, very hard to do for little to no benefit.
I very much share your concern. It poses a considerable risk to inpact in any way a core library such as Boost.MPL that has been in use for over a decade now and that is why I turn to the community for discussing this proposal.
I do believe it is possible to make sure the alternative implementation of Boost.MPL honours every requirement of its documentation with reasonable confidence, since it is easier for a pure functional language, but it is also possible that some code out there still breaks due to their reliance on undocumented behaviour (been there done that). Now should Boost care for such cases?
No. Any code using undocumented parts of a Boost library, or undocumented behavior which just happens to work with some release of some Boost library, is on its own. That can't be the concern of a library developer IMO.
However the responder has a good point that you need to be thorough in testing any change to Boost.MPL since it is such a core library of Boost. If you need help in testing MPL in an environment which may be difficult for you to replicate don't be afrad to ask on this mailing list.
Thank you Edward. No testing is too much testing, I’ll make sure this endeavour doesn’t turn into a fiasco. Regards, Bruno Dutra
On 02/03/2016 18:23, Bruno Dutra wrote:
More specifically, if sequences are explicitly folded, iterators are explicitly tracked or any other mandatorily recursive algorithm is used, then I agree with you that using Metal as a backend for Boost.MPL would only bring marginal improvements at most.
However, if mostly algorithms that may be somehow expressed in terms of variadic template expansion are used, such as transform, find, remove, replace, contains, partition, etc., then most surely dramatic improvements would be perceived.
Since you mentioned performance, I would like to clarify that Metal was not designed to be the fastest TMP library out there, nor it is advertised as such, rather I pose that it is just fast enough for mainstream metaprogramming and that’s already a couple of orders of magnitude faster than Boost.MPL in most cases. That means I actively avoided such optimizations as fast tracked recursion and unrolling, which tend to demand additional template specializations, which clutter the code base and thus impair clarity and maintenance. My goals were instead make sure Metal was as easy as possible to maintain and that is why I believe it is a good fit for Boost. I invite you and everyone else to briefly browse through the source code [1], so you can see I did try hard to keep it simple and easy to understand.
Some points there : - Brigand as library is on the road to be submitted to boost. But now, we need to make it more mature and complete. It's a valid question for us as at least 3 Boost Libraries developers asked us to do so so they can use it inside their library. Boost.Dispatch and Boost.SIMD, libraries I co-write, also use brigand internally. - Boost.MPL idioms from C++2003 are archaic by now. As Edouard pointed out, rewriting MPL in C++11 is a mere upgrade, a large effort for a meager gain. The road we choose to follow with Brigand was to provide a TMP library with updated idioms and so, an updated interface. - Compile time performances nowadays is probably the ONE issue people raise about complex (or even simple in some cases) template metaprogramming. To make TMP a day-to-day tool for average joe developer in the wild is to ensure that compile times are manageable. So I think focusing on CT-performance must be target #1 for any modern TMP library, hence our design choices in brigand. - We also figured out people want something between MPL and Hana. We're not in a process of being included in Boost for the sake of it but as said earlier, it's something we could do as the library matures. Brigand is maybe rewritable later as something ont he side of Hana or even disappear as a bunch of wrappers to siplify some Hana constructs. The paradigm shift induced by Hana is somethign to take into account.
2016-03-02 16:06 GMT-03:00 Joel FALCOU <joel.falcou@gmail.com>:
On 02/03/2016 18:23, Bruno Dutra wrote:
More specifically, if sequences are explicitly folded, iterators are explicitly tracked or any other mandatorily recursive algorithm is used, then I agree with you that using Metal as a backend for Boost.MPL would only bring marginal improvements at most.
However, if mostly algorithms that may be somehow expressed in terms of variadic template expansion are used, such as transform, find, remove, replace, contains, partition, etc., then most surely dramatic improvements would be perceived.
Since you mentioned performance, I would like to clarify that Metal was not designed to be the fastest TMP library out there, nor it is advertised as such, rather I pose that it is just fast enough for mainstream metaprogramming and that’s already a couple of orders of magnitude faster than Boost.MPL in most cases. That means I actively avoided such optimizations as fast tracked recursion and unrolling, which tend to demand additional template specializations, which clutter the code base and thus impair clarity and maintenance. My goals were instead make sure Metal was as easy as possible to maintain and that is why I believe it is a good fit for Boost. I invite you and everyone else to briefly browse through the source code [1], so you can see I did try hard to keep it simple and easy to understand.
Some points there :
- Brigand as library is on the road to be submitted to boost. But now, we need to make it more mature and complete. It's a valid question for us as at least 3 Boost Libraries developers asked us to do so so they can use it inside their library. Boost.Dispatch and Boost.SIMD, libraries I co-write, also use brigand internally.
Should I take it as an invitation for me to withdraw from my proposals? - Boost.MPL idioms from C++2003 are archaic by now. As Edouard pointed
out, rewriting MPL in C++11 is a mere upgrade, a large effort for a meager gain. The road we choose to follow with Brigand was to provide a TMP library with updated idioms and so, an updated interface.
Once again I should stress Metal is _not_ a mere remake of Boost.MPL. Do please take the time to browse through the example I set up on the documentation. [1] Please notice I made two separate yet complimentary proposals here: 1. Make Metal into a new version of Boost.MPL API, i.e. update idioms; 2. Reimplement Boost.MPL based on Metal for backward performance improvements.
- Compile time performances nowadays is probably the ONE issue people raise about complex (or even simple in some cases) template metaprogramming. To make TMP a day-to-day tool for average joe developer in the wild is to ensure that compile times are manageable. So I think focusing on CT-performance must be target #1 for any modern TMP library, hence our design choices in brigand.
Please allow me to disagree, targets #1 and #2 of any library must be correctness and maintainability**. Even though Metal isn't designed to be the fastest out there, please notice it does performs admirably for datasets well into the thousands, which should be far more than enough for an average Joe developer in the wild, who, mind you, won't be building static state machines of 10k nodes every other day. I do understand such use cases exist and must be addressed, but I don't think they fit the concept of everyday metaprogramming. You might argue there's no point in pushing TMP forward now that Boost.Hana is around, if not to reach extreme performance. Well, it's not because Python is around that we stopped pushing C++ forward have we? ** Incidentally, the following is quoted from the Boost Library Requirements [2] Design and Programming Aim first for clarity and correctness; optimization should be only a secondary concern in most Boost libraries. [1]: http://brunocodutra.github.io/metal/#parsing_raw_literals [2]: http://www.boost.org/development/requirements.html Regards, Bruno Dutra
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them.
I see no problem with this proposal, provided that the preprocessor switches in question are the boost.config compiler trait macros. This is essentially what ends up happening with various libraries at a more in-depth level anyway, and as long as the syntax, as you say, is transparent, it doesn't matter either way.
participants (12)
-
Andrey Semashev -
Bruno Dutra -
edouard＠fausse.info -
Edward Diener -
Jens Weller -
Joel FALCOU -
Louis Dionne -
Michael Marcin -
Paul Fultz II -
Peter Dimov -
Rene Rivera -
Soul Studios