Adds tuple_transform, which applies a callable to each tuple element and stores the results in another tuple. Also works with std::pair, but not with std::array.

I already opened aticket in the official boost tracker, but thought it is a better idea to directly provide a PR.

While working with cuda and boost::mp11 I noticed that cuda 9 does not work with boost::mp11, even this simple application fails:

#include <boost/mp11.hpp>
int main() {}

This seems to be a bug in the nvidia compiler >= 9, not boost, but this is a showstopper for using boost::mp11 together with a recent cuda version. Everything works fine with cuda 8. I didn't test an earlier version, but there is no C++11 before cuda 7 anyway.

I already figured out, what fails in the background in the nvcc (details are ​here), but now also found a work around for boost::mp11:

The problem occurs on code like this:

template<template<class...> class F, class... T> using mp_defer = mp_if<mp_valid<F, T...>, detail::mp_defer_impl<F, T...>, detail::mp_no_type>;

Everytime mp_if is used, the nvcc preprocessor tries to be "smart" and starts recursively replacing stuff so that in the end detail::mp_no_type... is given to the compiler (please don't ask why, some details are in the link above).

I figured out I can prevent nvcc from doing this with invoking another struct inbetween like this:

template<template<class...> class F, class... T>
struct cuda_workaround
{
    using type = mp_if<mp_valid<F, T...>, detail::mp_defer_impl<F, T...>, detail::mp_no_type>;
};

template<template<class...> class F, class... T>
using mp_defer = typename cuda_workaround< F, T... >::type;

This work around is needed on 5 places in the boost mp11 (see commit).

I added an intermediate struct in the detail namespace as seen above for every case if cuda 9 is used and now my code compiles with nvcc 9.

If the commit / PR needs adjustments to suit your style requirements, don't hesitate to ask. ;)

The latest trunk (pre-7.0) of clang and all previous releases fail compiling a simple:

#include <boost/mp11.hpp>

int main()
{}

when compiling for cuda C++: clang -x cuda.

The reason lies in some mismatch, probably between CUDA kernel starts parameters >>> and closing templates in combination with variadic template arguments.

Reported in clang here: https://bugs.llvm.org/show_bug.cgi?id=37013

This PR fixes the issue by just putting spaces in, conservatively, all places with triple+ > closing template brackets.

Intel compiler isn't listed as supported thus this is a feature request not a bug report.

Using the below alternative implementation (slight modification of the cppreference implementation of is_detected) for mp_valid reduces the failed tests from 9 to 2. Would it make sense to upload this with BOOST_WORKAROUND(BOOST_INTEL) as pull request? I currently have no idea how to work around the remaining issue(s). Any suggestion/help would be welcome.

namespace detail
{
template<typename...> using void_t = void;

template <class, template<class...> class F, class... T>
struct mp_valid_impl : mp_false {};

template <template<class...> class F, class... T>
struct mp_valid_impl<void_t<F<T...>>, F, T...> : mp_true {};
} // namespace detail                                                                                                                                                                                                                         

template<template<class...> class F, class... T> using mp_valid = typename detail::mp_valid_impl<void, F, T...>;

I'm not sure what the right name for these should be (the Python itertools module has an example for the first one that is named pairwise). These are fairly trivial to implement:

template <typename L, template <typename...> class F>
using mp_zip_tail_with = mp_transform<F, mp_pop_back<L>, mp_pop_front<L>>;

template <typename L>
using mp_zip_tail = mp_zip_tail_with<L, mp_list>;

But seem useful enough that should come batteries included (and possibly there's a more efficient implementation that doesn't rely on mp_pop_back).

On that note, mp_transform currently requires all the lists to have the same length. I think that's worth adding to the documentation (not really obvious, and the error if you get it wrong isn't particularly informative). Is it worth having a version of this that just takes the shortest list as zip?

In my journey of writing a cmake script to download and make available the boost library which you can see here, I saw that mp11's CMakeLists.txt doesn't follow the other boost libraries' pattern and I wonder why?

I know boost/cmake is not ready yet, but am I on the right path here?

GCC gives (potentially new) diagnostics https://compiler-explorer.com/z/TjjdserT1

/opt/compiler-explorer/libs/boost_1_78_0/boost/mp11/algorithm.hpp:445:102: error: '>=' should be '> =' to terminate a template argument list
  445 | struct mp_take_c_impl<N, L<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T...>, typename std::enable_if<N >= 10>::type>
      |                                                                                                      ^~
      |                                                                                                      > =
/opt/compiler-explorer/libs/boost_1_78_0/boost/mp11/algorithm.hpp:445:107: error: template argument 3 is invalid
  445 | struct mp_take_c_impl<N, L<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T...>, typename std::enable_if<N >= 10>::type>
      |                                                                                                           ^
/opt/compiler-explorer/libs/boost_1_78_0/boost/mp11/algorithm.hpp:445:114: error: expected unqualified-id before '>' token
  445 | struct mp_take_c_impl<N, L<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T...>, typename std::enable_if<N >= 10>::type>
      |                                                                                                                  ^

The diagnostics stop compilation. Older versions of GCC do not object, and neither does c++17 or higher.

Issue description: Found Boost\libs\mp11 build error C2672 in MSVC, this issue can be reproduced on c92d2d0b6fa9ae77094416f8142a8128c0424941. Could you please take a look?

Reproduce steps:

1. git clone -c core.autocrlf=true --recursive ​https://github.com/boostorg/boost.git f:\Boost
2. open a VS 2017 x86 command prompt and browse to f:\Boost
3. .\bootstrap
4. .\b2 headers variant=release --build-dir=..\out\x86rel address-model=32
5. .\b2 variant=release --build-dir=..\out\x86rel address-model=32
6. .\b2 -j4 variant=release --build-dir=..\out\x86rel libs\mp11\test

ErrorMessage: .\boost/mp11/detail/mp_count.hpp(111): error C2672: 'boost::mp11::detail::cx_count_if': no matching overloaded function found libs\mp11\test\mp_count_if.cpp(38): note: see reference to class template instantiation 'boost::mp11::detail::mp_count_if_impl<L1,std::is_const>' being compiled libs\mp11\test\mp_count_if.cpp(38): note: see reference to alias template instantiation 'boost::mp11::mp_count_if<L1,std::is_const>' being compiled .\boost/mp11/detail/mp_count.hpp(111): error C3206: 'boost::mp11::detail::cx_count_if': invalid template argument for 'P', missing template argument list on class template 'std::is_const' .\boost/mp11/detail/mp_count.hpp(95): note: see declaration of 'boost::mp11::detail::cx_count_if' .\boost/mp11/detail/mp_count.hpp(111): error C3206: 'boost::mp11::detail::cx_count_if': invalid template argument for 'P', missing template argument list on class template 'std::is_volatile' .\boost/mp11/detail/mp_count.hpp(95): note: see declaration of 'boost::mp11::detail::cx_count_if' .\boost/mp11/detail/mp_count.hpp(111): error C3206: 'boost::mp11::detail::cx_count_if': invalid template argument for 'P', missing template argument list on class template 'std::is_pointer' .\boost/mp11/detail/mp_count.hpp(95): note: see declaration of 'boost::mp11::detail::cx_count_if' .\boost/mp11/detail/mp_count.hpp(111): error C3206: 'boost::mp11::detail::cx_count_if': invalid template argument for 'P', missing template argument list on class template 'is_even' .\boost/mp11/detail/mp_count.hpp(95): note: see declaration of 'boost::mp11::detail::cx_count_if'

I'm trying to port some software from brigand (which sadly doesn't look maintained anymore) to boost mp11 and this is the only function I need that doesn't have an equivalent in mp11.

mp_split<L<T1_1, T1_2, ..., T1_n, S, T2_1, ..., T2_m, S, ...>, S> should be equal to L<L<T1_1, T1_2, ..., T1_n>, L<T2_1, T2_2, ..., T2_m>, ...>>

Here's the implementation in brigand: https://github.com/edouarda/brigand/blob/master/include/brigand/algorithms/split.hpp

This is a combination of mp_eval_if and mp_and. mp_and already shortcuts on the first substitution failure when mp_to_bool is applied to T or when the application yields mp_false. mp_eval_and would provide the same functionality for applications of meta functions F... on T.

template <class T, template<class>class F...> using mp_eval_and = ...

mp_eval_and<T, F0, F1, ...> is mp_false, if F0<T> is mp_false or a substitution failure. Otherwise it is mp_eval_and<T, F1, ...> and so on.

Example application for mp_eval_and

template <class T>
using is_unsigned_integral = mp_eval_and<T, std::is_integral, std::is_unsigned>;

The conversion bool -> int -> std::size_t triggers GCC sign conversion warning.

I don't know your policy about those warnings. Alternatively the CMake include path can be specified as SYSTEM.

I made a trivial change to the histogram develop branch today and started seeing these failures:

https://ci.appveyor.com/project/HDembinski/histogram-d5g5k/builds/44806268#L931

This is very puzzling and I don't how to fix this. Peter, can you help me, please?

The failures cannot originate from a change in boost histogram. The last time I tested the develop branch was at July 28th, where the appveyor tests ran through. https://ci.appveyor.com/project/HDembinski/histogram-d5g5k/builds/44309070#L900

I did some more testing in a virtual machine with msvc-14.3 installed and found that I am now getting this error even when I go back to boost-1.79.0 and boost-1.78.0 (histogram, mp11, everything). It is always complaining about that line.

So given all that evidence, I guess msvc-14.3 got a minor version update and that is causing the internal compiler error?

The code is at https://godbolt.org/z/KvjecnTe3. The code can be compiled if switching to clang 13.0.1, but gcc 11.2 or the trunk version fails. Interestingly, if I comment out line 22 and 23 as

 // boost::mp11::mp_list<enum_<Foo::A1>, int>,
 // boost::mp11::mp_list<enum_<Foo::A2>, double>,

then gcc can successfully compile the code. Any ideas?

Assume we want to invoke tuple_for_each or tuple_apply on the keys or values of a map. We can encode our projection inside the function object passed as argument, but it would be nicer to pass a unary function as optional third argument.

Consider this example

template<class... Pairs>
constexpr void reset_values1 (std::tuple<Pairs...>& map)
{
  mp11::tuple_for_each (map, [] (auto& p) {
    p.second = 0;
  });
}

template<class... Pairs>
constexpr void reset_values2 (std::tuple<Pairs...>& map)
{
    auto set_zero = [] (auto& x) {
      x = 0;
    };
    auto second = [] (auto& x) -> auto& {
      return x.second;
    };
    mp11::tuple_for_each (map, set_zero, second);
}

The second implementation is more verbose because we had to write some function objects, but it enables easier composition. mp11 doesn't have useful function objects to compose with this feature, but higher order function libraries do.

I just wanted to modernize my code - and try to use boost::mp11::mp_list instead of boost::mpl::vector in my FSM definitions.

Simplified code is as follows:

#include <iostream>
#include <boost/msm/back/state_machine.hpp>
#include <boost/msm/front/state_machine_def.hpp>

#include <boost/mp11/list.hpp>
#include <boost/mp11/algorithm.hpp>
#include <boost/mp11/mpl.hpp>

namespace msm = boost::msm;

namespace test_fsm 
{
struct play {};
struct stop {};
struct player_ : public msm::front::state_machine_def<player_>
{
    typedef int no_exception_thrown;
    typedef int no_message_queue;

    struct Empty : public msm::front::state<> 
    {
        template <class Event,class FSM>   void on_entry(Event const&,FSM& ) { std::cout << "entering: Empty" << std::endl; }
        template <class Event,class FSM>   void on_exit(Event const&,FSM& ) { std::cout << "leaving: Empty" << std::endl; }
    };
    struct Playing : public msm::front::state<>
    {
        template <class Event,class FSM>    void on_entry(Event const&,FSM& ) { std::cout << "entering: Playing" << std::endl; }
        template <class Event,class FSM>    void on_exit(Event const&,FSM& ) { std::cout << "leaving: Playing" << std::endl; }
    };

    typedef Empty initial_state;

    // transition actions
    void playing(play const&)  {  }
    void stop_playing(stop const&)  {  }
    
    typedef player_ p; 

    struct transition_table : boost::mp11::mp_list<
            _row < Empty , play        , Playing       >,
            _row < Playing , stop        , Empty       >
    > {};

    // Replaces the default no-transition response.
    template <class FSM,class Event>
    void no_transition(Event const& e, FSM&,int state)
    {
        std::cout << "no transition from state " << state
            << " on event " << typeid(e).name() << std::endl;
    }

    typedef msm::back::state_machine<player_> player;

    //
    // Testing utilities.
   //
   static char const* const state_names[] = { "Empty", "Playing" };

    void pstate(player const& p)
   {
       std::cout << " -> " << state_names[p.current_state()[0]] << std::endl;
   }
};

}

int main()
{
    test_fsm::player p2;
    p2.start();
    p2.process_event(test_fsm::play());
    p2.process_event(test_fsm::stop()); 
    return 0;
}

It compiles, but produces unexpected output:

entering: Empty
no transition from state 0 on event N8test_fsm4playE
no transition from state 0 on event N8test_fsm4stopE

While - with original version (just replacing mp11::mp_list with mpl::vector) it works as expected:

entering: Empty
leaving: Empty
entering: Playing
leaving: Playing
entering: Empty

It also works as expected with boost::fusion::vector.

I found one workaround - when using type-alias for defining transition table it works as expected:

    using transition_table = boost::mp11::mp_list<
            _row < Empty , play        , Playing       >,
            _row < Playing , stop        , Empty       >
    > ;

With type-alias it also works for other types boost::mpl::vector and boost::fustion::vector.

I am not sure what this inheritance is for, but all examples from boost::msm defines this transition tables that way.

The problem with boost::mp11::mp_list is probably here <boost/mp11/mpl.hpp> - but I am not sure that.

I asked the question about that on SO: https://stackoverflow.com/questions/68195912/boostmp11mp-list-cant-define-proper-transition-table-for-fsm-based-on-boost - but not get much attention.

You can play with the problem on compiler explorer: https://godbolt.org/z/jTEnxPMTj

The problem is not related to version of boost or compiler.

Problem:

• There is no easy way to quote metafunction directly with lambda expressions.

Solution:

• Add mp_quote_expr.

Note:

• mp_quote_expr requires C++20.

First sorry for the ugly name, I could not think of anything better. I know mp11 is mostly a lib for nice manipulation of lists, but one feature that really worked great for me is the tuple_for_each.

I used it to implement nice(IMHO) dispatching on runtime value. "Problem" is that it is not optimally efficient since I am doing an equivalent of many ifs, instead of a switch or if else. Code example with basic idea is here(code is missing propagation of return value of the lambda, ignores alignment... but I hope general idea is clear).

https://godbolt.org/z/1TscGs

I have no idea what is the proper way to handle default case, I would suspect that there could be a tag type, but in my use I do not really need it since I cover all cases, so hard for me to judge if it would be a good addition.