10

I am wondering if it is possible to write a C++ equivalent of the Python function map, using the automatic return type deduction feature. What I have in mind is something like this:

vector<int> input({1,2,3});
auto output=apply(input,[](int num){return num*num;});

//output should be a vector {1,4,9}

I do know about std::transform, but in the present state of affairs, writing a range loop seems easier.

SPMP
  • 1,181
  • 1
  • 9
  • 24
  • 3
    Using std::transform would be the way to go - what do you think is wrong with this solution? It is quite concise in my opinion. – ajshort Oct 27 '15 at 21:54
  • A loop doesn't require much more typing, right? And a loop is more readable I feel (there are people who agree with me it seems http://stackoverflow.com/questions/3885317/stdtransform-using-c0x-lambda-expression). – SPMP Oct 27 '15 at 21:57
  • I think it would be slightly less typing. I guess readability is personal preference - I would personally just use a loop for a simple case like this. – ajshort Oct 27 '15 at 21:59
  • I also always thought that `std::transform()` is less powerful than Python's `map()` but actually it is more powerful because you can decide on any `output_iterator` that the `std::transform()` should write to. This means you can very quickly change from e.g. printing (`ostream_iterator<>(cout)`) to aggregating a set of unique values by using `insert_iterator<>(set, set.begin())` (of course with correct syntax, but you get the idea) – emvee Oct 27 '15 at 22:11
  • I agree, but sometimes, all I need is the python map() – SPMP Oct 27 '15 at 22:12

4 Answers4

7

Baum mit Augen's answer is most of the way there. Just takes a few more steps to support anything that is for-each-able:

template <typename C, typename F>
auto apply(C&& container, F&& func)
{
    using std::begin;
    using std::end;

    using E = std::decay_t<decltype(std::forward<F>(func)(
        *begin(std::forward<C>(container))))>;

    std::vector<E> result;
    auto first = begin(std::forward<C>(container));
    auto last = end(std::forward<C>(container));

    result.reserve(std::distance(first, last));
    for (; first != last; ++first) {
        result.push_back(std::forward<F>(func)(*first));
    }
    return result;
}

We can even go one step further and make this SFINAE-able by not using C++14 auto deduction and instead moving the failure up to the deduction phase. Start with a helper for begin/end:

namespace adl_helper {
    using std::begin;
    using std::end;

    template <typename C>
    auto adl_begin(C&& c) -> decltype(begin(std::forward<C>(c))) {
        return begin(std::forward<C>(c));
    }

    template <typename C>
    auto adl_end(C&& c) -> decltype(end(std::forward<C>(c))) {
        return end(std::forward<C>(c));
    }    
}

using adl_helper::adl_begin;
using adl_helper::adl_end;

And then use that to deduce E earlier:

using adl_helper::adl_begin;
using adl_helper::adl_end;

template <typename C,
          typename F,
          typename E = std::decay_t<decltype(std::declval<F>()(
              *adl_begin(std::declval<C>())
              ))>
           >
std::vector<E> apply(C&& container, F&& func)
{
    /* mostly same as before, except using adl_begin/end instead
       of unqualified begin/end with using
    */
}

Now we can test at compile time if some container/function pair is apply-able, and the error is a deduction failure instead of a usage failre:

int arr[] = {1, 2, 3};
auto x = apply(arr, []{ return 'A'; });

main.cpp: In function 'int main()':
main.cpp:45:52: error: no matching function for call to 'apply(int [3], main()::<lambda()>)'
    auto x = apply(arr, []() -> char { return 'A'; });
                                                    ^
main.cpp:29:16: note: candidate: template<class C, class F, class E> std::vector<E> apply(C&&, F&&)
 std::vector<E> apply(C&& container, F&& func)
                ^
main.cpp:29:16: note:   template argument deduction/substitution failed:
main.cpp:25:50: error: no match for call to '(main()::<lambda()>) (int&)'
           typename E = decltype(std::declval<F>()(
                                                  ^

As pointed out, this would not handle a container of input iterators well. So let's fix it. We need something to determine the size of the container. If the container has a size() member function, we can use that. Otherwise if the iterators do not have category input_iterator_tag (don't know of any other way to distinguish input iterators...), we can use that. Otherwise, we're kind of out of luck. A good way of doing decreasing order of preference like this is to introduce a chooser hierarchy:

namespace details {
    template <int I> struct chooser : chooser<I-1> { };
    template <> struct chooser<0> { };
}

And then just walk down:

namespace details {
    template <typename C>
    auto size(C& container, chooser<2>) -> decltype(container.size(), void())
    {
        return container.size();
    }

    template <typename C,
              typename It = decltype(adl_begin(std::declval<C&>()))
              >
    auto size(C& container, chooser<1>) 
    -> std::enable_if_t<
        !std::is_same<std::input_iterator_tag,
            typename std::iterator_traits<It>::iterator_category
        >::value,
        size_t>
    {
        return std::distance(adl_begin(container), adl_end(container));
    }

    template <typename C>
    size_t size(C& container, chooser<0>)
    {
        return 1; // well, we have no idea
    }
}

template <typename C>
size_t size(C& container)
{
    return size(container, details::chooser<10>{});
}

Then we can use size() to reserve() our vector to the best of our ability:

template <typename C,
          typename F,
          typename E = std::decay_t<decltype(std::declval<F>()(
              *adl_begin(std::declval<C>())
              ))>
           >
std::vector<E> apply(C&& container, F&& func)
{
    std::vector<E> result;
    result.reserve(size(container));

    for (auto&& elem : container) {
        result.push_back(std::forward<F>(func)(std::forward<decltype(elem)>(elem)));
    }
    return result;
}
Barry
  • 286,269
  • 29
  • 621
  • 977
  • Neat, nice generalization of my answer; +1. May I ask: Why the perfect forwarding of the function argument? The standard library (which, of course, is not perfect) passes by value. Is there a notable benefit? – Baum mit Augen Oct 28 '15 at 22:52
  • Btw, *"anything that is for-each-able"* is not quite true as `std::for_each` supports input iterators and `result.reserve(std::distance(first, last));` would break stuff with those. (Before you ask: I will not deliver an example where that would make sense, I am just being pedantic.) – Baum mit Augen Oct 28 '15 at 23:10
  • @BaummitAugen Input iterators handled :) – Barry Oct 29 '15 at 12:15
  • How does one use this? The prior example just returns a constant. I'm thinking something like: apply(intValues, [](elem) { return elem*2; }); – user9170 Oct 23 '18 at 20:47
  • @UserOneFourTwo What prior example returns a constant? – Barry Oct 23 '18 at 21:17
  • auto x = apply(arr, []{ return 'A'; }); How would I get it to do something with an item of arr? – user9170 Oct 24 '18 at 14:21
  • @UserOneFourTwo I don't understand what you're asking, sorry. – Barry Oct 24 '18 at 14:44
  • How do I use apply() as defined above, on the array [1,2,3] to return the array [3,6,9] with the function body { return item*3; } ? – user9170 Oct 24 '18 at 17:57
6

This can certainly be done and would probably look something like this:

template <class Container, class Function>
auto apply (const Container &cont, Function fun) {
    std::vector< typename
            std::result_of<Function(const typename Container::value_type&)>::type> ret;
    ret.reserve(cont.size());
    for (const auto &v : cont) {
        ret.push_back(fun(v));
    }
    return ret;
}

If you want to be super general and handle C arrays and everything, you might need to add a couple of overloads for the special cases.

Live example

Baum mit Augen
  • 49,044
  • 25
  • 144
  • 182
4

This has already been discussed in comments, but I think it should also be given as an answer: The function std::transform from <algorithm> does what you want.

The following code works for me:

#include <vector>
#include <algorithm>
using namespace std;

//...

vector<int> input({1,2,3});
transform(input.begin(), input.end(), input.begin(), [](int num){return num*num;});
lhk
  • 27,458
  • 30
  • 122
  • 201
3

This works with your example, and with most of the containers. I use std::transform, because it can be optimized for each stl iterator. I started out from Baum mit Augen's answer, which was deleted later.

template<typename Container, typename Function>
using _mapT = std::vector<typename std::result_of<Function(const typename Container::value_type&)>::type>;

template <typename Container, typename Function>
_mapT<Container, Function> map(const Container &container, Function &&f)
{
    _mapT<Container, Function> ret; ret.reserve(container.size());
    std::transform(container.begin(), container.end(), std::back_inserter(ret), std::forward<Function>(f));
    return ret;
}
  • 1
    That will default construct or value initialize an unknown number of arbitrarily complex types before reassigning them. That is not a good idea. If you really want to use `std::transform` here (which is fine), have a look at `std::back_inserter`). – Baum mit Augen Oct 27 '15 at 22:27
  • @BaummitAugen I ran my version before posting, so this one works with msvc2015. The back_inserter is indeed much better :). I removed C++14 features, this should run with C++11. – Csaba Bálint Oct 27 '15 at 22:43
  • This is almost fine, but `_mapT` is an implementation reserved identifier at global scope, so this is only legal when wrapped in a different scope. I also don't see why you should introduce a new name in the first place, even if you want to go C++11, you can use trailing return types. – Baum mit Augen Oct 27 '15 at 22:49
  • For that you need the `->decltype(..)` and inside you have to type the same (or very similar) long thing. `_mapT` is not reserved because underscore lowercase can be used [link](http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier). – Csaba Bálint Oct 27 '15 at 22:55
  • It cannot be used at the global namespace. *"Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace."* From the link you posted. – Baum mit Augen Oct 27 '15 at 22:56
  • Putting it in some detail namespace is a good practice though. – Csaba Bálint Oct 27 '15 at 22:57
  • Yes, that you can do. – Baum mit Augen Oct 27 '15 at 22:58
  • I'm sorry, but isn't this code wrong? You shouldn't reserve memory if you use back_inserter.. – SPMP Oct 27 '15 at 23:01
  • 1
    @user2308211 You are probably confusing `reserve` and `resize`. `reserve` is fine and a good idea if you know the size, `resize` would be wrong. – Baum mit Augen Oct 27 '15 at 23:04
  • @CsabaBálint *"I use std::transform, because it is optimized to each container."* That is not quite true either. First of all, `std::transform` deals with iterators, not containers. Second, `std::transform` is commonly implemented as a loop (see e.g. [here](https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01499_source.html#l04189)), the compiler does the optimizing later. You can not expect a performance gain by switching from loops to `std::transform`. Again, using it here is completely fine, it is just the reason that is wrong. – Baum mit Augen Oct 27 '15 at 23:18
  • 1
    @BaummitAugen I know I was vague again. It can be implemented for each container's iterator, and due to its restrictions the compiler can optimize even more. – Csaba Bálint Oct 27 '15 at 23:24
  • Why is this correct? From the documentation: "std::transform does not guarantee in-order application". – sygi Mar 11 '17 at 13:35