Tagged: cpp

2013/08/09

Function Composition

The usefulness of higher order functions is hard to dispute, you can safely and easily write functions which combine the functionality of other functions. The most basic of higher order functions is function composition, the topic of this post.

There is no standard way to compose functions, especially since there is no standard way to resolve a function’s argument and return types. Good thing that we have function traits! I will also be making use of the generalized function evaluation discussed previously.

To keep the discussion simple, I will only discuss unary functions, though conceivably one could make some clever use of std::forward_as_tuple and make a very complete and complex implementation.

Let’s start with the basics:

#include <functional>

#include "eval.h"
#include "function_traits.h"

template<class F, class G>
auto compose(F&& f, G&& g)
    -> std::function<typename function_traits<F>::return_type(
        typename function_traits<G>::template argument<0>::type)>
{
    using F_traits = typename function_traits<F>;
    using G_traits = typename function_traits<G>;

    static_assert(F_traits::arity == 1, "error: only unary functions can be composed.");
    static_assert(G_traits::arity == 1, "error: only unary functions can be composed.");

    using Arg = typename G_traits::template argument<0>::type;

    return [=](Arg arg){return eval(f,eval(g,arg));};
}

Given two functions, f(x) and g(y), compose will give us h(y) = compose(f,g) = f(g(y)). Note the use of static asserts to enforce the use of unary functions as well as to determine the argument type for the returned function.

The trailing return type uses the function_traits to cast the lambda to a valid function object. In c++14, the return type can be omitted entirely, and frankly it’s a huge improvement. Just look at that thing.

An example of this in action:

#include <iostream>

int main()
{
    auto double_then_add_three = compose(
        [](int n){return n+3;},
        [](int n){return n*2;}
    );

    for (unsigned i = 0; i < 10; ++i)
        std::cout << double_then_add_three(i) << " ";

    return 0;
}

Which outputs as expected:

3 5 7 9 11 13 15 17 19 21

Let’s try making an operator version of this. I will be choosing operator* as my composition operator.

template<class F, class G>
auto operator*(F&& f, G&& g)
{
    return compose(std::forward<F>(f),std::forward<G>(g));
}

This works quite well, until we try and combine function pointers.

#include <iostream>

int add_one(int n){return n+1;}
int times_two(int n){return n*2;}

int main()
{
    // fine
    auto double_then_add_three = [](int n){return n+3;} * [](int n){return n*2;};

    // error!
    auto double_then_add_one = &add_one * &times_two;

    return 0;
}

This is because the compiler is trying to multiply the two pointers and that makes absolutely no sense. How can we get around this? We can write our own custom operators. (I feel really bad about this! Don’t hate me!)

First we have to wrap our pointer in another object, we also add a test to see if a type is a wrapper:

template<class T>
struct wrapper
{
    wrapper(T t):value(t){};

    T value;
};

template<>
struct wrapper<void>
{};

template<class T>
struct is_wrapper
{
    enum{ value = false };
};

template<class T>
struct is_wrapper<wrapper<T>>
{
    enum{ value = true };
};

Now for the new composition operator, very similar but with some minor changes:

template<
    class F, class G,
    class = typename std::enable_if<!is_wrapper<F>::value>::type
    >
auto operator*(F&& f, G&& g)
{
    return compose(std::forward<F>(f),std::forward<G>(g));
}

template<class T>
auto operator*(T&& t, wrapper<void> v)
{
    return wrapper<T>(std::forward<T>(t));
}

template<class T, class F>
auto operator*(wrapper<T>&& t, F&& f)
{
    return compose(t.value,f);
}

#define COMPOSE * wrapper<void>() *

We can now use the macro COMPOSE as an operator which behaves exactly like compose. The macro causes the left operand to be placed in a wrapper, which then can be passed to the compose operator.

This workaround also works for objects which have their own operator* but it’s not pretty and will definitely raise some flags if you use this in production.

The end result is quite nice though, and you can see this for yourself:

#include <iostream>

int increment(int n){return n+1;}
int times_two(int n){return n*2;}

int main()
{
    auto double_then_add_three = [](int n){return n+3;} * [](int n){return n*2;};
    std::cout << double_then_add_three(20) << " ";

    auto echo = [](const std::string& s){return s+" "+s;};
    auto echo_length = &std::string::size * echo;
    std::cout << echo_length("hello") << " ";

    auto some_func = &increment COMPOSE &times_two COMPOSE &increment COMPOSE &increment;
    std::cout << some_func(-4);

    std::cout << "\n";
}

Which gives the output:

43 11 -3

2013/08/05

Function Traits

C++11 has added the incredibly useful type_traits library. However, beyond std::is_function there isn’t really much going on for functions. Rolling your own function traits is not very difficult, and this post will show you how!

A good place to start is free functions. Using templates, it’s easy to unpack the return type, arity and argument types for a function:

template<class F>
struct function_traits;

// function pointer
template<class R, class... Args>
struct function_traits<R(*)(Args...)> : public function_traits<R(Args...)>
{};

template<class R, class... Args>
struct function_traits<R(Args...)>
{
    using return_type = R;

    static constexpr std::size_t arity = sizeof...(Args);

    template <std::size_t N>
    struct argument
    {
        static_assert(N < arity, "error: invalid parameter index.");
        using type = typename std::tuple_element<N,std::tuple<Args...>>::type;
    };
};

Which can be used like this:

float free_function(const std::string& a, int b)
{
    return (float)a.size() / b;
}

int main()
{
    using Traits = function_traits<decltype(free_function)>;

    static_assert(Traits::arity == 2,"");
    static_assert(std::is_same<Traits::return_type,float>::value,"");
    static_assert(std::is_same<Traits::argument<0>::type,const std::string&>::value,"");
    static_assert(std::is_same<Traits::argument<1>::type,int>::value,"");

    return 0;
}

The use of decltype is necessary because we need the type of the function, not the function itself. Here, decltype(free_function) resolves to the function pointer, but it is entirely possible to do something like function_traits<int(char)>.

Through template pattern matching, the compiler is capable of determining R and Args.... We can then alias return_type and get the arity from the parameter pack. Getting the arguments is slightly more complex, unpacking Args... into a tuple and accessing elements using std::tuple_element.

Functionality can be extended to function-like objects such as member function pointers and member object pointers:

// member function pointer
template<class C, class R, class... Args>
struct function_traits<R(C::*)(Args...)> : public function_traits<R(C&,Args...)>
{};

// const member function pointer
template<class C, class R, class... Args>
struct function_traits<R(C::*)(Args...) const> : public function_traits<R(C&,Args...)>
{};

// member object pointer
template<class C, class R>
struct function_traits<R(C::*)> : public function_traits<R(C&)>
{};

Const and non-const member functions are treated as separate types. This basically treats member function/object pointers as functions which take a reference to the appropriate class.

To handle functors and std::function objects (technically also a functor), we can now implement the default specialization:

// functor
template<class F>
struct function_traits
{
    private:
        using call_type = function_traits<decltype(&F::type::operator())>;
    public:
        using return_type = typename call_type::return_type;

        static constexpr std::size_t arity = call_type::arity - 1;

        template <std::size_t N>
        struct argument
        {
            static_assert(N < arity, "error: invalid parameter index.");
            using type = typename call_type::template argument<N+1>::type;
        };
};

template<class F>
struct traits<F&> : public traits<F>
{};

template<class F>
struct traits<F&&> : public traits<F>
{};

This will determine the type traits of the member operator() function then use that to determine the function traits of the functor itself. The two extra specializations will also strip any reference qualifiers to prevent wierd errors.

Like type traits, these function traits are very useful to debug templates. What was once an indecipherable wall of compiler errors can now be easily caught by a single static assertion. As we move on to more complex functional concepts, these will become invaluable.

I leave the implementation of is_callable, which determines if an object is a function or function-like (function pointer, member function/object pointer, functor), to the reader.

2013/08/03

Generalized Function Evaluation

I often find myself wishing there was a generalized way of calling functions and function-like “things”.

Functors are obviously quite function-like. Member function pointers can be treated like function where the object pointer as just another parameter. Member object pointers can be treated like a function which retrieves a member from a pointed object.

Now with the new c++11 standard, it is possible to do this quite easily!

#include <type_traits>
#include <utility>

// functions, functors, lambdas, etc.
template<
    class F, class... Args,
    class = typename std::enable_if<!std::is_member_function_pointer<F>::value>::type,
    class = typename std::enable_if<!std::is_member_object_pointer<F>::value>::type
    >
auto eval(F&& f, Args&&... args) -> decltype(f(std::forward<Args>(args)...))
{
    return f(std::forward<Args>(args)...);
}

// const member function
template<class R, class C, class... Args>
auto eval(R(C::*f)() const, const C& c, Args&&... args) -> R
{
    return (c.*f)(std::forward<Args>(args)...);
}

template<class R, class C, class... Args>
auto eval(R(C::*f)() const, C& c, Args&&... args) -> R
{
    return (c.*f)(std::forward<Args>(args)...);
}

// non-const member function
template<class R, class C, class... Args>
auto eval(R(C::*f)(), C& c, Args&&... args) -> R
{
    return (c.*f)(std::forward<Args>(args)...);
}

// member object
template<class R, class C>
auto eval(R(C::*m), const C& c) -> const R&
{
    return c.*m;
}

template<class R, class C>
auto eval(R(C::*m), C& c) -> R&
{
    return c.*m;
}

The first overload of eval covers almost every single case. Furthermore, note the use of universal references and forwarding which automatically handles const and reference qualifiers.

The next three overloads handle const and non-const member function pointers. Additional parameters of C& are added as if they were parameters of the original functions.

Member object pointers are then treated as functions which take a reference to an object then return a reference to its member.

The use of std::enable_if prevents the first overload from greedily instantiating for member function pointers.

Now to show it in action:

#include <iostream>

struct Bloop
{
    int a = 10;
    int operator()(){return a;}
    int operator()(int n){return a+n;}
    int triple(){return a*3;}
};

int add_one(int n)
{
    return n+1;
}

int main()
{
    Bloop bloop;

    // free function
    std::cout << eval(add_one,0) << "\n";

    // lambda function
    std::cout << eval([](int n){return n+1;},1) << "\n";

    // functor
    std::cout << eval(bloop) << "\n";
    std::cout << eval(bloop,4) << "\n";

    // member function
    std::cout << eval(&Bloop::triple,bloop) << "\n";

    // member object
    eval(&Bloop::a,&bloop)++; // increment a by reference
    std::cout << eval(&Bloop::a,bloop) << "\n";

    return 0;
}

Which gives the expected output:

Note: Be careful with pointers to overloaded functions, the compiler will not be able to determine which overload to use. You will need to either explicitly cast to a function pointer or std::function object with the desired type.

Edit: Thank you to STL for pointing out member object pointers should return references, not values.

Edit2: Thanks to Aaron McDaid for pointing out a few more mistakes.

	gnzlbg on Composing Continuations
	whanhee on Function Composition
	whanhee on Continuation Passing Style
	ciber on Function Composition
	ciber on Function Composition