[review][mp11] Reminder of ongoing formal review
The formal review of Mp11 continues until (and including) Monday, July 24th. There have been four formal reviews so far. I would like to ask the Boost community for two favours: 1. Please postpone the discussions about CMake and the future directions of Boost until the formal review has ended. 2. Please review the Mp11 library instead. If you disagree with any of the above, please contact me off-list. Here is the call for review once more: The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11/tree/master Please answer the following questions in your review [4]: 1. Should Mp11 be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain? [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html [4] http://www.boost.org/community/reviews.html
On Fri, Jul 21, 2017 at 10:36 AM, Bjorn Reese via Boost < boost@lists.boost.org> wrote:
The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1].
Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review.
I want to say something up front about my bias that may be useful to the review manager. I do (and have done) a significant amount of metaprogramming (TMP specifically). I've almost always done it in the context of SFINAE-constraining a template or computing the return type of a function. I've never needed a compile-time set or map. Parameter packs or other type lists have always been sufficient for my needs, and I use those somewhat infrequently.
* Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases.
I don't need mp11 or anything like it for simple cases; among those of us who do TMP, simple things are now (meaning in C++ >=14) trivial. It seems to be a very nice fit for the more complex ones.
* Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists.
* Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits.
Both of these points are borne out by my experiments with the library, and are great to see. The whole point of a library is code reuse, right?
Mp11 can be found here:
* Documentation: https://rawgit.com/pdimov/mp11 /master/doc/html/mp11.html
* Source code: https://github.com/pdimov/mp11/tree/master
Please answer the following questions in your review [4]:
1. Should Mp11 be accepted into Boost? Please state all conditions for acceptance explicity.
Yes, I vote to accept. No conditions.
2. What is your evaluation of the design?
The design is very nice. I especially like the interoperability with arbitrary type sequences and metafunctions mentioned above. However, if the library is targeting eventual standardization, it should either target the needs of C++ >=20 (with if constexpr and probably concepts), or should at least have a portion of it that does, so that part can be proposed as a standalone entity with usage experience. 3. What is your evaluation of the implementation?
It seems very straightforward and easy to follow (though I did not look at all of it).
4. What is your evaluation of the documentation?
A lot of people have complained that there isn't enough of it, but I found it to be just right. Perhaps it's a bit Spartan for non-TMP folks, but why do they want to use it? Perhaps inlining the "Simple C++ metaprogramming" articles would help? Is mp11 intended to be used as a direct replacement for mpl? If so, a brief discussion of that would be useful in the docs. Specifically, how one might convert existing mpl-using code to use mp11. 5. What is your evaluation of the potential usefulness of the library?
For me, very low. I am convinced that others can get a lot of use out of the more complex features, like the set and map operations. I would also be more convinced to use it if I knew where it fit in the metaben.ch rankings. 6. Did you try to use the library? With what compiler? Did you have
any problems?
Yes. I tried to use just a few of the list operations and algorithms with Clang 4. No problems.
7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I read all the docs (that was fast :), and spent an hour or so playing with the code.
8. Are you knowledgeable about the problem domain?
Yes. Zach
Zach Laine wrote:
Yes, I vote to accept. No conditions.
Thanks. :-)
Is mp11 intended to be used as a direct replacement for mpl?
This has never been my intent, to be honest.
I would also be more convinced to use it if I knew where it fit in the metaben.ch rankings.
Well you could just open metaben.ch and see, could you not?
On Fri, Jul 21, 2017 at 12:03 PM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
Zach Laine wrote:
I would also be more convinced to use it if I knew where it fit in the metaben.ch rankings.
Well you could just open metaben.ch and see, could you not?
Ha! I could have sworn I read multiple people claim that this was not available, so I did not look. Thanks. Zach
Hi, not a review yet. I´m just wondering: would the implementation below perfom better than the recursive version of mp_find_impl ? I think it should perform better when one uses mp_find several times in the same list. It also compiles in vs2013. template <class ... T> struct mp_find_impl_helper; template <> struct mp_find_impl_helper<> { struct tag {}; static mp_size_t<0> get(const tag&, ...); }; template <class T, class ... Rest> struct mp_find_impl_helper<T, Rest...> : mp_find_impl_helper<Rest...> { using mp_find_impl_helper<Rest...>::get; using parent_tag = typename mp_find_impl_helper<Rest...>::tag; struct tag : parent_tag {}; static mp_size_t<1 + sizeof...(Rest)> get(const tag&, mp_identity<T>); }; template<class L, class V> struct mp_find_impl; template <template <class ...> class L, class ... T, class V> struct mp_find_impl<L<T...>, V> { using helper = mp_find_impl_helper<T...>; using tag = typename helper::tag; using R = decltype(helper::get(tag(), mp_identity<V>())); using type = mp_size_t<sizeof...(T) - R::value>; }; // Regargs // robhz
Roberto Hinz wrote:
Hi,
not a review yet. I´m just wondering: would the implementation below perfom better than the recursive version of mp_find_impl ? I think it should perform better when one uses mp_find several times in the same list. It also compiles in vs2013.
It performs better across the board (for repeated finds). Would you be willing to submit a pull request that replaces the current mp_find_impl with this one, so that your authorship is preserved in the commit history?
template <class ... T> struct mp_find_impl_helper;
template <> struct mp_find_impl_helper<> { struct tag {}; static mp_size_t<0> get(const tag&, ...); };
template <class T, class ... Rest> struct mp_find_impl_helper<T, Rest...> : mp_find_impl_helper<Rest...> { using mp_find_impl_helper<Rest...>::get;
using parent_tag = typename mp_find_impl_helper<Rest...>::tag;
struct tag : parent_tag {};
static mp_size_t<1 + sizeof...(Rest)> get(const tag&, mp_identity<T>); };
template<class L, class V> struct mp_find_impl;
template <template <class ...> class L, class ... T, class V> struct mp_find_impl<L<T...>, V> { using helper = mp_find_impl_helper<T...>;
using tag = typename helper::tag;
using R = decltype(helper::get(tag(), mp_identity<V>()));
using type = mp_size_t<sizeof...(T) - R::value>; };
Roberto Hinz wrote:
Hi,
not a review yet. I´m just wondering: would the implementation below perfom better than the recursive version of mp_find_impl ? I think it should perform better when one uses mp_find several times in the same list. It also compiles in vs2013.
It performs better across the board (for repeated finds).
Upon further experimentation, while it does perform very well for repeated finds such as those done by this test case: using L1 = mp_iota_c<300>; template<class T> using F = mp_find<L1, T>; using L2 = mp_transform<F, L1>; static_assert( std::is_same<L1, L2>::value, "L1 != L2" ); it has a large one-time cost in both time and heap space, making it unsuitable for N in the thousands. Still a significant improvement over the recursive version, but on balance, not over the constexpr-based one. Very nice work nevertheless.
El 23/07/2017 a las 14:42, Peter Dimov via Boost escribió:
Hi,
not a review yet. I´m just wondering: would the implementation below perfom better
Roberto Hinz wrote: than > the recursive version of mp_find_impl ?
I think it should perform better when one uses mp_find several times in > the same list. It also compiles in vs2013.
It performs better across the board (for repeated finds).
Upon further experimentation, while it does perform very well for repeated finds such as those done by this test case:
using L1 = mp_iota_c<300>; template<class T> using F = mp_find<L1, T>; using L2 = mp_transform<F, L1>; static_assert( std::is_same<L1, L2>::value, "L1 != L2" );
it has a large one-time cost in both time and heap space, making it unsuitable for N in the thousands.
The following alternative based on bool sequences seems to perform very well for the mp_iota_c case (basically, mp_find runs out of heap space in my machine for mp_iota_c<300> whereas mp_find2 takes 4-5 s). Don't know if mp_find2 stands up for other scenarios: template<bool... B> struct mp_find2_bools{}; template<bool... B> struct mp_find2_bools<false,false,false,false,false,false,false,false,false,false,B...> {static constexpr std::size_t value=10+mp_find2_bools<B...>::value;}; template<> struct mp_find2_bools<false,false,false,false,false,false,false,false,false> {static constexpr std::size_t value=9;}; template<> struct mp_find2_bools<false,false,false,false,false,false,false,false> {static constexpr std::size_t value=8;}; template<> struct mp_find2_bools<false,false,false,false,false,false,false> {static constexpr std::size_t value=7;}; template<> struct mp_find2_bools<false,false,false,false,false,false> {static constexpr std::size_t value=6;}; template<> struct mp_find2_bools<false,false,false,false,false> {static constexpr std::size_t value=5;}; template<> struct mp_find2_bools<false,false,false,false> {static constexpr std::size_t value=4;}; template<> struct mp_find2_bools<false,false,false> {static constexpr std::size_t value=3;}; template<> struct mp_find2_bools<false,false> {static constexpr std::size_t value=2;}; template<> struct mp_find2_bools<false> {static constexpr std::size_t value=1;}; template<> struct mp_find2_bools<> {static constexpr std::size_t value=0;}; template<bool... B> struct mp_find2_bools<false,false,false,false,false,false,false,false,false,true,B...> {static constexpr std::size_t value=9;}; template<bool... B> struct mp_find2_bools<false,false,false,false,false,false,false,false,true,B...> {static constexpr std::size_t value=8;}; template<bool... B> struct mp_find2_bools<false,false,false,false,false,false,false,true,B...> {static constexpr std::size_t value=7;}; template<bool... B> struct mp_find2_bools<false,false,false,false,false,false,true,B...> {static constexpr std::size_t value=6;}; template<bool... B> struct mp_find2_bools<false,false,false,false,false,true,B...> {static constexpr std::size_t value=5;}; template<bool... B> struct mp_find2_bools<false,false,false,false,true,B...> {static constexpr std::size_t value=4;}; template<bool... B> struct mp_find2_bools<false,false,false,true,B...> {static constexpr std::size_t value=3;}; template<bool... B> struct mp_find2_bools<false,false,true,B...> {static constexpr std::size_t value=2;}; template<bool... B> struct mp_find2_bools<false,true,B...> {static constexpr std::size_t value=1;}; template<bool... B> struct mp_find2_bools<true,B...> {static constexpr std::size_t value=0;}; template<typename L,typename V> struct mp_find2_impl; template<template<typename...> class L,typename... T,typename V> struct mp_find2_impl<L<T...>,V>:mp_find2_bools<std::is_same<T,V>::value...>{}; template<typename L,typename V> using mp_find2=mp_size_t<mp_find2_impl<L,V>::value>; Joaquín M López Muñoz
El 24/07/2017 a las 12:28, Peter Dimov via Boost escribió:
Joaquin M López Muñoz wrote:
The following alternative based on bool sequences seems to perform very well for the mp_iota_c case (basically, mp_find runs out of heap space in my machine for mp_iota_c<300> whereas mp_find2 takes 4-5 s).
Just to clarify, what compiler? MSVC?
Microsoft Visual Express 2015 for Windows Desktop Version 14.0.23107.0 D14REL Joaquín M López Muñoz
Joaquin M López Muñoz wrote:
El 24/07/2017 a las 12:28, Peter Dimov via Boost escribió:
Joaquin M López Muñoz wrote:
The following alternative based on bool sequences seems to perform very well for the mp_iota_c case (basically, mp_find runs out of heap space in my machine for mp_iota_c<300> whereas mp_find2 takes 4-5 s).
Just to clarify, what compiler? MSVC?
Microsoft Visual Express 2015 for Windows Desktop Version 14.0.23107.0 D14REL
Roberto's version also performs very well in this case. I haven't timed it yet but is seems even faster.
On 7/21/2017 11:36 AM, Bjorn Reese via Boost wrote:
The formal review of Mp11 continues until (and including) Monday, July 24th.
There have been four formal reviews so far.
I would like to ask the Boost community for two favours:
1. Please postpone the discussions about CMake and the future directions of Boost until the formal review has ended.
2. Please review the Mp11 library instead.
If you disagree with any of the above, please contact me off-list.
Here is the call for review once more:
The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1].
Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review.
* Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases.
* Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists.
* Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits.
Mp11 can be found here:
* Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html
* Source code: https://github.com/pdimov/mp11/tree/master
Please answer the following questions in your review [4]:
1. Should Mp11 be accepted into Boost? Please state all conditions for acceptance explicity.
YES. It is good enough currently to be accepted.
2. What is your evaluation of the design?
The design based on parameter packs and template aliases moves TMP, as specified by MPL library idioms, into the C++11 world. The library does not attempt to be as revolutionary as Hana but it offers an easier path to the many who have used MPL under C++03.
3. What is your evaluation of the implementation?
I did not look at it.
4. What is your evaluation of the documentation?
I think the formal Overview and Definitions were presented properly. Obviously the two introductory papers mentioned in the Overview are excellent but the details of those papers will probably be daunting to many C++ programmers. I would suggest that the first topic of the first paper, "C++11 changes the playing field" up until "Type lists and mp_rename" be included directly in the mp11 docs as a separate topic, perhaps under the title "MPL versus mp11". I realize that this creates a redundancy in the doc, but I feel that those explanations explain more to the TMP programmer having used MPL and attempting to understand how TMP might be used with C++11 constructs, than anything else, and so need to be in the main document where it is immediately noticeable. The rest of the documentation, especially the specifically correct terseness of the reference, then falls into place much more easily. The only other thing in the documentation which I might criticize was the arrangement of functionality in the reference. I think all sub-topic functionality should be in alphabetic order in the left panel of the doc. I actually missed the indexing functionality of a list, which I thought must be there, because the mp_at_c/mp_at was not in the alphabetic sequence in the left panel I might expect.
5. What is your evaluation of the potential usefulness of the library?
It is obviously useful as a much easier syntactical way of create complex templates using C++11 and beyond. The MPL library was and is an immense achievement. Moving to c++11 other TMP idioms are needed and there is plenty of room for alternatives. So I have no problem with mp11 and hana coexisting as advances and alternatives.
6. Did you try to use the library? With what compiler? Did you have any problems?
I ran the tests in the test directory with gcc-7.1 in c++11 mode, msvc-14.1 in c++14 mode which is its lowest mode, and clang-4.0 in c++11 mode. All tests passed. I could have tried numerous other previous releases of these compilers in c++11 mode but I was satisfied that if the latest versions of those compilers worked flawlessly, the library worked correctly and any previous version failures which might occur would be the result of the compiler and not mp11.
7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
A few hours at the end after spending an hour here and there acquainting myself both the mp11 and C++11 advances which I did not know as completely as I should have.
8. Are you knowledgeable about the problem domain?
I am decently knowledgeable and have used MPL and understand it pretty well.
On Fri, 21 Jul 2017 17:36:11 +0200 Bjorn Reese via Boost <boost@lists.boost.org> wrote:
The formal review of Mp11 continues until (and including) Monday, July 24th. [...snip..] Please answer the following questions in your review [4]:
1. Should Mp11 be accepted into Boost? Please state all conditions for acceptance explicity.
Yes, I think it should be accepted.
2. What is your evaluation of the design?
I like the simplicity and consistency. In particular, I like how it is designed to explicitly work with any template-class parameter pack, so that `variant` and other custom user types can be manipulated directly. Also, moving away from MPLs vector metafunctions that return different types is a huge benefit - its frustrating trying to get any partial template "match" with that design.
3. What is your evaluation of the implementation?
I did not read the entirety of the code (unfortunately), but the parts I did read were what I would expect. The primary negative is that some of the techniques are likely non-obvious to someone new to metaprogramming (the SFINAE techniques in `mp_and_` for instance), but I am not aware of any obvious alternative solutions that requires less C++ hidden knowledge with equivalent performance.
4. What is your evaluation of the documentation?
I think the links to the blog post at the beginning should be made internal to the documentation so that it is included with the Boost release. The documentation is also less rigorous than the documentation for MPL. An example would be: For an Mp11 integral constant type T, T::value is an integral constant in the C++ sense. For example, std::integral_constant<int, 7>, or struct N { static int constexpr value = 2; }; which is the entirety of the discussion about integral constants. Should `decltype(T::value)` only be a built-in type? Does it ever make sense for user types with proper operator overloads? The MPL documentation was overly verbose at times, but I think it could help negotiate expected behavior between users and the library maintainers. For example, when trying to squash some bugs in the C++11 fusion::vector, I realized that all but one C++03 fusion sequence could implicitly-construct from a longer sequence (the remaining elements were ignored). The documentation never mentioned this behavior, but it also never specified that the sequences had to be identical in length. I decided to "bring-back" that behavior in C++11 fusion::vector, because I found a way to do it with no discernable impact. But if it was specified as a non-feature, perhaps the maintenance is easier. Unfortunately I have no specific recommendations other than to perhaps continually update the design section in particular as the library is being updated/maintained.
5. What is your evaluation of the potential usefulness of the library?
The prior discussion about metaprogramming being easier with C++11 was an interesting one. Since it is easier, many bespoke implementations are likely to exist in codebases. But I can see a real advantage to internal use by several Boost libraries. `make_integer_sequence` has been implemented numerous times (fusion and spirit x3 both have one now IIRC), and the easiest implementation is linear-recursive and therefore sub-optimal. In another instance I managed to write a decent `mp_and_` with the inevitable MSVC tantrum discovered shortly later. So if included into Boost, I might try to persuade Joel to get fusion's C++11 code and spirit x3 to use mp11 in a few places where performance could be improved with hopefully no broken client code. I suspect there are _many_ places throughout Boost where this process could occur.
6. Did you try to use the library? With what compiler? Did you have any problems?
I did not try to use the library, I primarily read the implementation instead. Reading the implementation might be more useful than using it in this context. I was also interested in several similar libraries that have been discussed on the mailing list. After reviewing them quickly, I think this is the best solution to this specific problem domain _right now_. I primarily like the explicit goal to treat all template-class variadics identically, grouping similar metafunctions in a single file (the implementations are terse; brigand _seems_ like it would take longer to include/load all of the different files for some of the algorithms something like fusion or spirit would need), more focused/complete documentation, and not tackling a larger/different problem domain (kvasir).
7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I spent probably 3-4 hours reading the documentation, code, mailing list posts, and took a minimal amount of time to look at several alternative libraries (metal, meta, brigand, kvasir).
8. Are you knowledgeable about the problem domain?
Fairly knowledgeable. I've hacked at the implementations of spirit and fusion a bit, so I know the exact number of times to hit your head against the wall to make that SFINAE expression work. Always 8. Lee
participants (7)
-
Bjorn Reese -
Edward Diener -
Joaquin M López Muñoz -
Lee Clagett -
Peter Dimov -
Roberto Hinz -
Zach Laine