|
Boost : |
Subject: Re: [boost] [review][mp11] Formal review of Mp11
From: Brook Milligan (brook_at_[hidden])
Date: 2017-07-17 02:54:49
> On Jul 16, 2017, at 7:00 PM, Peter Dimov via Boost <boost_at_[hidden]> wrote:
>
> Brook Milligan wrote:
>> Before I write a review, I have a couple of questions that are the outgrowth of having been using mp11 since some time after the first two articles of Peterâs. That should suggest I generally like the library, which I do.
>>
>> Nevertheless, in my code, I have found need for the following additional metafunctions:
>>
>> - mp_map_keys: creates a list of keys from a map
>
> With metaprogramming libraries, it's always quite difficult to decide what to include and what to leave out, as there are so many useful things that are also one-liners. As everyone has probably surmised by now, I prefer minimalism, that is, omit by default, only include when a clear need arises.
Fair enough. The challenge is figuring out when a clear need actually does arise. I raised this set in part to see if anyone else speaks up to suggest that they are needed.
> mp_map_keys, for example, is mp_transform<mp_first, M>.
Yes, that was my implementation.
>> - mp_is_set: type trait to determine whether a type is a set, i.e., has unique elements
>
> This at the moment is std::is_same<S, mp_unique<S>>, although as I mentioned, perhaps either mp_is_set or mp_distinct should indeed be provided.
Yes, that was my implementation, too. It does feel like this is worth including as mp_distinct, but your call.
>> - mp_is_map: type trait to determine whether a type is a map, i.e., has a unique set of keys
>
> This is mp_is_set<mp_map_keys<M>>, although not quite if M has an element that is not a list.
Yes, that was also my implementation. I just punted on the question of whether or not mp_map_keys would always work. Given that it might not, this could be motivation for a more robust implementation in the library.
>> I have also found need for a metafunction that takes a map and a set of keys and returns a map with only elements with the selected keys. This is perhaps more specialized, but I can also see a general use case.
>
> template<class M, class L> using mp_map_subset =
> mp_copy_if<M, mp_bind<mp_set_contains, L, mp_bind<mp_first, _1>>::template fn>;
>
> mp_copy_if_q, when I add it, will eliminate the need for the ::template fn here.
My implementation was a bit more complicated, because I didnât quite get how to use mp_bind correctly. Perhaps more than suggesting that this be implemented, this suggests more complete documentation on bind. At least to me, this is considerably more complex than some of the simpler metafunctions and therefore warrants more documentation, including examples.
This is likely true for many of the algorithms.
Cheers,
Brook
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk