[boost] [review][mp11] Reminder of ongoing formal review

[Bjorn Reese via Boost]

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

_______________________________________________
Unsubscribe & other cha

[Zach Laine via Boost]

On Fri, Jul 21, 2017 at 10:36 AM, Bjorn Reese via Boost <

Post by Bjorn Reese via Boost
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.

Post by Bjorn Reese via Boost
* 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.

Post by Bjorn Reese via Boost
* 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?

Post by Bjorn Reese via Boost
* Documentation: https://rawgit.com/pdimov/mp11
/master/doc/html/mp11.html
* Source code: https://github.com/pdimov/mp11/tree/master
1. Should Mp11 be accepted into Boost? Please state all conditions
for acceptance explicity.

Yes, I vote to accept. No conditions.

Post by Bjorn Reese via Boost
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).

Post by Bjorn Reese via Boost
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

Post by Bjorn Reese via Boost
any problems?

Yes. I tried to use just a few of the list operations and algorithms with
Clang 4. No problems.

Post by Bjorn Reese via Boost
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.

Post by Bjorn Reese via Boost
8. Are you knowledgeable about the problem domain?

Yes.

Zach

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org

[Peter Dimov via Boost]

Post by Zach Laine via Boost
Yes, I vote to accept. No conditions.

Thanks. :-)

Post by Zach Laine via Boost
Is mp11 intended to be used as a direct replacement for mpl?

This has never been my intent, to be honest.

Post by Zach Laine via Boost
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?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Zach Laine via Boost]

On Fri, Jul 21, 2017 at 12:03 PM, Peter Dimov via Boost <

Post by Peter Dimov via Boost

Post by Zach Laine via Boost
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jason Rice via Boost]

Hello, my name is Jason Rice, and this is my first Boost review so please
take that into consideration. I'm also new to this mailing list thing so
let me know if I did something wrong here.

Please consider the following review for the proposed Boost.Mp11 library:

1. Should Mp11 be accepted into Boost? Please state all conditions
for acceptance explicity.

ACCEPT. No conditions

2. What is your evaluation of the design?

The interface is very straight forward.
It is mostly templates but the user is not burdened with accessing a
nested "type" with every metafunction.
The list algorithms are flexible in that they take any kind of list which
is very handy.
I did notice that the user is burdened with ensuring that a list is not
const or they will just get a "implicit instantiation of undefined
template" error which doesn't really point to the problem.
(e.g. when using mp_append with many lists)

The `mp_` prefix is welcome if this is destined for the `std` namespace.
The `tuple_apply` could probably just be called `apply` since appears to
be a shim of `std::apply`.
The interface of map functions accepting any list of list is very nice.

3. What is your evaluation of the implementation?

The implementation is very clean. I looked at `mp_map_find_impl` and it
is very concise and easy to understand.
I did find it annoying though that some of the public facing functions
are defined inside detail files which makes the source code a little more
difficult to traverse.
I'd like to see mp_product perform on par with the other libs on
metaben.ch

4. What is your evaluation of the documentation?

For the interface, it gets the job done.
The table of contents has some text wrapping that could be fixed.
There is no instructions for installation that I could find anywhere.
It fails to mention that Boost.Config is a dependency. (AFAICT)

5. What is your evaluation of the potential usefulness of the library?

I use Boost.Hana quite a bit. I'm currently using a library like this to
help where optimization for compile-time performance is needed so it is
definitely useful.

6. Did you try to use the library? With what compiler? Did you have
any problems?

I used it in my library Nbdl to augment my use of Boost.Hana in a couple
of places.
The compiler is a recent pull of the Emscripten fork of clang targeting
X86.
I did get stuck for a while on a weird error I mentioned before because a
used a const list.
I didn't like having to also install Boost.Config. (I'm not using the
Boost monolith build)

7. How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?

I spent a few hours on it.
I used mp_append and mp_with_index in my lib with great results.
I just looked at the implementation of mp_map_find.
I scoured the documentation looking for stuff and seeing what else was
available.

8. Are you knowledgeable about the problem domain?

Yes, I have done TMP and I am also a contributor to Boost.Hana.



Jason Rice

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov via Boost]

Post by Jason Rice via Boost
ACCEPT. No conditions

Thanks.

Post by Jason Rice via Boost
I'd like to see mp_product perform on par with the other libs on
metaben.ch

It was on par but then Bruno optimized his. :-)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Roberto Hinz via Boost]

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

_______________________________________________
Unsubscribe & other changes

[Peter Dimov via Boost]

Post by Roberto Hinz via Boost
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?

Post by Roberto Hinz via Boost
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>;
};

_______________________________________________
Unsubscribe & other c

[Peter Dimov via Boost]

Post by Peter Dimov via Boost

Post by Roberto Hinz via Boost
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/lis

[Joaquin M López Muñoz via Boost]

Post by Peter Dimov via Boost

Post by Roberto Hinz via Boost
Hi,
not a review yet.
I´m just wondering: would the implementation below perfom better

than > the recursive version of mp_find_impl ?

Post by Roberto Hinz via Boost
I think it should perform better when one uses mp_find several

times in > the same list.

Post by Roberto Hinz via Boost
It also compiles in vs2013.

It performs better across the board (for repeated finds).

Upon further experimentation, while it does perform very well for
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

_______________________________________________
Unsubscribe & other changes: http://lists.b

[Peter Dimov via Boost]

Post by Joaquin M López Muñoz via Boost
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?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/

[Joaquin M López Muñoz via Boost]

Post by Peter Dimov via Boost

Post by Joaquin M López Muñoz via Boost
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mail

[Peter Dimov via Boost]

Post by Joaquin M López Muñoz via Boost

Post by Peter Dimov via Boost

Post by Joaquin M López Muñoz via Boost
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.


_______________________________________________
Unsubscribe & other changes: http:

[Edward Diener via Boost]

Post by Bjorn Reese via Boost
The formal review of Mp11 continues until (and including) Monday, July
24th.
There have been four formal reviews so far.
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.
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.
https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html
* Source code: https://github.com/pdimov/mp11/tree/master
1. Should Mp11 be accepted into Boost? Please state all conditions
for acceptance explicity.

YES. It is good enough currently to be accepted.

Post by Bjorn Reese via Boost
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.

Post by Bjorn Reese via Boost
3. What is your evaluation of the implementation?

I did not look at it.

Post by Bjorn Reese via Boost
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.

Post by Bjorn Reese via Boost
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.

Post by Bjorn Reese via Boost
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.

Post by Bjorn Reese via Boost
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.

Post by Bjorn Reese via Boost
8. Are you knowledgeable about the problem domain?

I am decently knowledgeable and have used MPL and understand it pretty well.


_______________________________________________
Unsubscribe & other changes: http://