Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Boost.MP11 when feasible #66

Merged
merged 2 commits into from Jan 16, 2019

Conversation

@CromwellEnage
Copy link
Collaborator

commented Jan 16, 2019

  • Add are_tagged_arguments_mp11 and is_argument_pack_mp11 metafunctions when Boost.MP11 is usable.
  • Predicate requirements can be encoded as Boost.MP11-style quoted metafunctions as well as by MPL binary metafunction classes.
  • Argument packs qualify as Boost.MP11-style lists as well as MPL sequences.
  • Internal components and test programs use Boost.MP11 and C++11 type traits vice MPL and Boost.TypeTraits when Boost.MP11 is usable.
Support Boost.MP11 when feasible
* Add are_tagged_arguments_mp11 and is_argument_pack_mp11 metafunctions when Boost.MP11 is usable.
* Predicate requirements can be encoded as Boost.MP11-style quoted metafunctions as well as by MPL binary metafunction classes.
* Argument packs qualify as Boost.MP11-style lists as well as MPL sequences.
* Internal components and test programs use Boost.MP11 and C++11 type traits vice MPL and Boost.TypeTraits when Boost.MP11 is usable.

@eldiener eldiener merged commit 4a5356b into boostorg:develop Jan 16, 2019

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@CromwellEnage CromwellEnage deleted the CromwellEnage:feature_mp11 branch Jan 17, 2019

@pdimov

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2019

You are not supposed to specialize mp11::detail types, sorry.

@CromwellEnage

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 18, 2019

Oh. Are there viable alternatives, or do I just need to revert the portion of the changes that allow the ArgumentPack models to also be MP11 lists?

@pdimov

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2019

What is, and what isn't, an mp11 list is well defined and not subject to specializations. empty_arg_list, for example, isn't. arg_list<TaggedArg,Next,EmitsErrors> is a list of exactly size 3, with elements exactly TaggedArg, Next, and EmitsErrors.

@CromwellEnage

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 18, 2019

I'm still looking for a workaround. I'm currently stumped at conceptually being unable to do:

template <typename ...KeyTaggedArgTuples>
struct arg_list;

template <>
struct arg_list<> : public empty_arg_list {};

template <typename Key, typename TaggedArg, typename ...Rest>
struct arg_list< mp11::mp_list<Key,TaggedArg>, Rest...> : public arg_list<Rest...> {};

The key problem lies in inheritance, of course, so it'll take me a while to find a way to not rely on it.

@pdimov

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2019

If you have arg_list<KeyTagged...>, you don't need inheritance or specialization for the zero-arg case. Assuming that the problem is that you want to do lookup by Key and that the inner tuples are indeed mp_list<Key, TaggedArg> (or pair, or tuple, or arg_tuple, it doesn't matter), you can then use mp_map_find for the lookup.

@pdimov

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2019

That's assuming that arg_list only stores type information. If it has data members, things will be trickier.

namespace boost { namespace parameter {

template <typename TaggedArg0, typename ...TaggedArgs>
using are_tagged_arguments_mp11 = ::boost::mp11::mp_bool<

This comment has been minimized.

Copy link
@pdimov

pdimov Jan 18, 2019

Contributor

This shouldn't be needed. The original is usable as-is.

This comment has been minimized.

Copy link
@CromwellEnage

CromwellEnage Jan 19, 2019

Author Collaborator

I'll remove that and is_argument_pack_mp11 on the next pull request I submit.

This comment has been minimized.

Copy link
@CromwellEnage

CromwellEnage Jan 21, 2019

Author Collaborator

Okay, they're removed.

@pdimov

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2019

It does, so you'll need to inherit arg_list<KeyTagged...> from KeyTagged... and then have

template<class Key, class TaggedArg> arg_tuple<Key, TaggedArg>& get( arg_tuple<Key, TaggedArg>& x ) { return x; }

and get<Key>(list) will get you the correct base (which will contain the TaggedArg as a data member.)

This is similar to how std::tuple is implemented, except there indices are used for the keys. An example tuple implementation is here:

https://github.com/boostorg/beast/blob/develop/include/boost/beast/core/detail/tuple.hpp

except it's more complex than we need here because it needs to generate an index sequence, whereas we already have the list of keyed bases, so we can just inherit from it directly.

@pdimov

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2019

CromwellEnage added a commit to CromwellEnage/parameter that referenced this pull request Jan 19, 2019
Modify MP11 support
These are breaking changes to PR boostorg#66.

* Remove are_tagged_arguments_mp11 and is_argument_pack_mp11.  They were reviewed as redundant.
* Remove MP11 support for ArgumentPack models for now.  (This feature relied on templates that were not supposed to be specialized.)
@CromwellEnage CromwellEnage referenced this pull request Jan 19, 2019
@CromwellEnage

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 21, 2019

Thanks for your suggestions, @pdimov. I'll be using them for a different library I've been working on.

For PR #70, I didn't want to lose the ability to use the bracket operator to index by key and retrieve the corresponding argument, so I figured out a way for flat_like_arg_list to inherit from either arg_list or empty_arg_list, and I made a corresponding tagged_argument_list_of_1 that inherits from either tagged_argument or tagged_argument_rref.

I'd be grateful if you could review the new PR to ensure that I'm using MP11 properly this time, at least.

@pdimov

This comment has been minimized.

Copy link
Contributor

commented Jan 21, 2019

operator[] is trivial to implement, see https://godbolt.org/z/3Qids9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.