8

I am currently working on a library where I am chaining function objects.

I am creating a function template that takes a callable object (std::function at the moment) and is parametrized on the output and input type of the function. Here is a simplified version of what I am defining:

template <typename In, typename Out>
std::vector<Out> process(std::vector<In> vals, std::function< Out(In) > func)
{
    // apply func for each value in vals
    return result;
}

The problem I am having is on usage. It seems that when I pass a lambda, the compiler cannot deduce the type correctly, so complains that the function doesn't exist:

std::vector<string> strings;
// does NOT compile
auto chars = process(strings,
        []( std::string s ) -> char
        {
            return s[0]; // return first char
        }
);

If I explicitly wrap the lambda in std::function, the program compiles:

std::vector<string> strings;
// DOES compile
auto chars = process(strings,
        std::function< char(std::string) >(
        []( std::string s ) -> char
        {
            return s[0]; // return first char
        })
);

I haven't tested passing function pointers or function objects yet, but it seems like it will be difficult for the compiler to deduce the the In and Out parameters if I'm not directly passing the explicit std::function object.

My question is this: is there a way to get around this, so that I can deduce the input/return type of a callable object without explicitly mentioning them at the call site?

Perhaps parametrize the template on the function type instead of the input/return types? Essentially I need to deduce the In and Out type for an arbitrary callable. Perhaps some kind of auto/decltype trick for the return type of the template function?

Thank you.

Alexander Kondratskiy
  • 4,156
  • 2
  • 30
  • 51
  • It's just an example of course, but this is exactly what `std::transform` does. – Jon Dec 06 '12 at 22:41
  • 1
    yes I am fully aware of that. Transform works on iterators but I need to create another object parametrized on the return type of the transformation. As far as I am aware, transform doesn't need those types as it can just do `*out = *in++; ++out;` without ever knowing the value_types as it just deals with the iterators. The example simplifies things quite a bit- the requirement is knowledge of the input/return type. – Alexander Kondratskiy Dec 06 '12 at 22:45

2 Answers2

9

I think what you can do is to create an intermediate return type deducing function which uses decltype to determine the arguments to be passed to the actual function object:

template <typename Out, typename In>
std::vector<Out> process_intern(std::vector<In> vals, std::function< Out(In) > func)
{
    // whatever
}

template <typename In, typename Func>
auto process(std::vector<In> vals, Func func) -> std::vector<decltype(func(vals[0]))>
{
    return process_intern<decltype(func(vals[0]))>(vals, func);
}

Of course, you may want to consider implementing the logic in process() directly anyway unless there is a reason to type erase the function type.

Dietmar Kühl
  • 150,225
  • 13
  • 225
  • 380
  • Cool! You raise a good point about type erasure, I don't think I need it. Neat trick to get the return type, thanks! – Alexander Kondratskiy Dec 07 '12 at 00:30
  • The compiler somehow figures out that `decltype(func(vals[0]))` maps to the parameter list of `template process_intern`. I was unaware that the compiler could deduce template arguments from a non-trivial `decltype` expression in this fashion. A surprising trick. – damienh Dec 07 '12 at 10:33
  • @damienh: All `decltype(func(vals[0]))` does is finding the return type of a `func(vals[0])`. The resulting type is, however, explicitly specified when calling `process_intern()`. – Dietmar Kühl Dec 07 '12 at 10:42
8

is there a way to get around this, so that I can deduce the input/return type of a callable object without explicitly mentioning them at the call site?

No. User-defined conversions are not considered in template argument deduction. The compiler have to come up with In and Out such that the type of the parameter and the type of the argument have to match (almost) exactly, but they never will in this case.

Perhaps parametrize the template on the function type instead of the input/return types

Yes, that's what is normally done (take a look at the standard library algorithms, for example)

Cubbi
  • 46,567
  • 13
  • 103
  • 169