Subject: Re: [boost] Formal Review Request: mp11
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-03-19 17:51:27
Le 19/03/2017 à 12:06, Peter Dimov via Boost a écrit :
> Vicente J. Botet Escriba wrote:
>
>> About your mp_count example. Compare your definition with this the
>> HOF one
>>
>> template <class TL, class V>
>> using mp_count_if<TL, P> = mp_plus<transform<TL, P>;
>
> First, you need to keep in mind that the code in the article compiled
> and worked at the time on the compilers that I had available, which
> included Visual Studio 2013. Using mp_transform was a good way to
> crash MSVC and remains so to this day, which is why the
> implementations often inline it by hand.
>
> Second, the above doesn't work because P<T>::value is allowed to be 42.
I'm not sure this should be the case, but if it was, then, the predicate
passed to transform should be a little bit adapted.
|mp_plus<|||mp_transform_f<TL, |compose<mp_to_bool_f, P>|>
>
>> template <class TL, class V>
>> using mp_count<TL, V> = mp_count_if<TL, is_same_t<_1,V>>;
>
> This - assuming that is_same_t is a template alias - cannot be made to
> work. Template aliases are evaluated eagerly and is_same_t<_1, V>
> gives you mp_true or mp_false depending on whether V is _1 (the
> literal _1) or not.
>
> You either have to use std::is_same<_1, V> and make the algorithms
> take and evaluate such lambdas by replacing placeholders and looking
> at ::type, or you need to bind or curry is_same_t. mp_bind<is_same_t,
> _1, V>::invoke, if it existed (it's a few lines, I'll probably add it)
> or mp_quote<is_same_t, V>::invoke.
>
You know what I mean. is_same<_1,V> should be a meta-function class.
Being able to use HOF makes meta-programming code simpler.
I was not thinking on making the algorithms do any analysis of the place
holders. I was just thinking on providing some specializations
template <class T>
struct is_same<_1, T> {
template <class U>
using invoke = is_same<U,T>;
};
or using something like Meta lambdas
template <class T> struct is_same<_1, T> : lambda<_1,
lazy::is_same<_1,T> {};
mp_quote<is_same_t, V> would work as well.
> (I'm considering renaming ::invoke to something shorter such as ::fn.)
BTW, mp_quote does more than quoting. It is doing some binding. I've
proposed the names it bind_front/bind_back that follows the new
bind_front/bind_back for normal programming
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0356r0.html)
Have you considered the possibility to provide algorithms taking HOF as
well as template aliases?
>
>> BTW, your mp_plus doesn't take a type list as parameter.
>
> It doesn't. There's an annoying dilemma here as most functions are
> useful in either form. mp_second<L> for instance takes a list, but
> mp_second<T...> would also have been useful. Not sure what to do here.
Maybe we need both.
>
>> About mp_contains. I've not yet finished the second article yet. IMO,
>> we need different concepts as we can have different implementations.
>> I believe mp_contains is an example where we can have different
>> implementations for type list and for type set.
>
> It does, see mp_contains and mp_set_contains in the actual mp11
> source. The latter requires the elements to be unique, although the
> data structure is still a list. I like Lisp.
>
Yes, I've see it now.
BTW I'm missing how we build a mp set. It is with inherit<>? Could we
have an empty set?
Why mp11 provides two ways to insert elements in a set push_back and
push_front?
I guess that we can use all the other mp_ functions that work for type
list with type set.
>> About C++11, C++14, C++17. I believe that meta-programming can
>> profit a lot of C++17 fold expressions.
>
> That belief is not necessarily true, but there are places where fold
> expressions are obviously useful, such as mp_plus. mp_fold can also be
> rewritten in their terms, but the performance gains are
> disappointingly small, although it does considerably increase the list
> size limit that can be handled without the compiler crashing.
>
> We'll add BOOST_NO_CXX17_FOLD_EXPRESSIONS at some point, presumably.
> Support is currently a bit hard to detect as Clang doesn't define an
> __is_feature for it. (I already had to make creative use of fold
> expressions to work around a Clang 3.9+ bug with mp_find.)
I understand that we are not yet ready to write portable C++17 code.
Best,
Vicente