In order to really understand C++17 fold expression, I have written a function append for containers :
#include <iostream>
#include <vector>
#include <list>
// fold expression
template<typename T, typename U, template<typename> typename... Args>
inline void append_impl(std::vector<T>& v, Args<U>... args) noexcept
{
static_assert((std::is_constructible_v<T,U>));
std::cout << "append_impl version one " << std::endl;
(v.insert(std::end(v),
std::begin(args),
std::end (args)), ...);
}
//fold expression
template<typename T, typename... Args>
inline void append_impl(std::vector<T>& v, Args&&... args) noexcept
{
static_assert((std::is_constructible_v<T, Args&&> && ...));
std::cout << "append_impl version two " << std::endl;
(v.push_back(std::forward<Args>(args)), ...);
}
// fold expression
template<typename T, typename... Args>
inline void append(std::vector<T>& v, Args&&... args) noexcept
{
(append_impl(v, args), ...);
}
int main()
{
std::vector<int> a = {1,2};
std::vector<int> b = {3,4};
std::vector<int> c = {5,6};
std::list<int> d = {15,16};
append(a,b,c, std::vector<int>{8,9}, 10, 11, 12, 13, 14, d);
for(const auto& e : a)
{
std::cout << e << " ";
}
std::cout << std::endl;
return 0;
}
this works fine and give me the result :
append_impl version one
append_impl version one
append_impl version one
append_impl version two
append_impl version two
append_impl version two
append_impl version two
append_impl version two
append_impl version one
1 2 3 4 5 6 8 9 10 11 12 13 14 15 16
But I have a question from this code :
In the first version of append_impl, args is pass by copy. I wanted to use universal references (in Scott Meyers sens) to avoid this, but append_impl(std::vector<T>& v, Args<U>&&... args) give me a compilation error.
rog.cc: In instantiation of 'void append_impl(std::vector<T>&, Args&& ...) [with T = int; Args = {std::vector<int, std::allocator<int> >&}]':
prog.cc:18:15: required from 'void append(std::vector<T>&, Args&& ...) [with T = int; Args = {std::vector<int, std::allocator<int> >&, std::vector<int, std::allocator<int> >&, std::vector<int, std::allocator<int> >, int, int, int, int, int, std::__cxx11::list<int, std::allocator<int> >&}]'
prog.cc:29:59: required from here
prog.cc:10:3: error: static assertion failed
10 | static_assert((std::is_constructible_v<T, Args&&> && ...));
| ^~~~~~~~~~~~~
prog.cc:12:15: error: no matching function for call to 'std::vector<int>::push_back(std::vector<int>&)'
12 | (v.push_back(std::forward<Args>(args)), ...);
Why and what can I do to avoid copy ?
Following issues with your code:
You forgot to #include<type_traits>.
You forgot to forward in append:
(append_impl(v, std::forward<Args>(args)), ...);
Your template template parameter in append_impl is a bit problematic. Because it is written as template<typename> typename... Args it assumes that the template passed to it takes one template parameter. std::list (and other containers) take multiple template arguments (although the other ones are defaulted).It is not entirely clear whether such a template should be valid for your template template parameter.
GCC accepts it, while Clang doesn't (see https://godbolt.org/z/LY9r-k). I think that after resolution of CWG issue 150 GCC is correct in accepting the code, but I haven't checked in detail.
In any case, this problem can be easily avoided by changing the parameter to template<typename...> typename... Args, which accepts templates with arbitrarily many parameters.
Your actual issue: Universal references (or forwarding references) do only work if a template parameter T is directly used as T&& in a function parameter. If you use it inside a function parameters' template argument, the rules for reference collapse resulting in the forwarding behavior of universal references do not apply.
Args<U>&&... args is always a rvalue reference, no matter what reference qualification U has.
Therefore your code does not compile if you try to forward a lvalue reference to this function template which always expects a rvalue reference.
You should probably write one template overload for rvalue references and one for const lvalue references:
template<typename T, typename U, template<typename...> typename... Args>
inline void append_impl(std::vector<T>& v, const Args<U>&... args) noexcept
template<typename T, typename U, template<typename...> typename... Args>
inline void append_impl(std::vector<T>& v, Args<U>&&... args) noexcept
Then you have however the problem that a non-const lvalue reference will be a better match for the second template overload taking Args&& directly, so you need to add another overload:
template<typename T, typename U, template<typename...> typename... Args>
inline void append_impl(std::vector<T>& v, Args<U>&... args) noexcept
{
append_impl(v, std::as_const(args)...);
}
(requires #include<utility>)
In general the way you are trying to identify containers is not save. It will fail for all types that are formed from template classes and are not containers.
Instead you could select the correct function overload by SFINAE on the container interface that you are going to use, i.e. std::begin(arg), std::end(arg) and the insert call. You can use expression SFINAE to do so.
Alternatively you can write a type trait for the well-formedness of these expressions and use a single overload for append_impl that chooses the implementation based on a if constexpr checking the type trait.
In C++20 this will be doable in a much simpler way, using concepts.
There also doesn't seem to be any reason that append_impl takes Args as a parameter pack. It is only ever called with one parameter for Args.
Related
I'm trying to port some code written for GCC (8.2) to be compilable by Clang:
#include <tuple>
struct Q{};
using TUP = std::tuple<Q>;
template<typename Fn>
inline
void feh(Fn&, const std::tuple<>*)
{}
template<typename Fn, typename H>
inline
void feh(Fn& fn, const std::tuple<H>*)
{
fn(H{});
}
template<typename Fn, typename H, typename... R>
inline
void feh(Fn& fn, const std::tuple<H, R...>*)
{
fn(H{});
using Rest = const std::tuple<R...>*;
feh<Fn, R...>(fn, static_cast<Rest>(nullptr));
}
template<typename Tuple, typename Fn>
inline
void fe(Fn& fn, const Tuple * tpl = nullptr)
{
feh(fn, tpl);
}
int main()
{
auto r = [] (Q const&) {};
TUP tup;
fe<TUP>(r, &tup);
}
GCC 8.2 (and 12.1) compiles the code just fine. However, Clang 11.0.0 (and 14.0.0) complains that the call from fe to feh is ambiguous between void feh(Fn& fn, const std::tuple<H>*) [with Fn = (lambda at <source>:38:14), H = Q] and void feh(Fn& fn, const std::tuple<H, R...>*) [with Fn = (lambda at <source>:38:14), H = Q, R = <>].
https://godbolt.org/z/5E9M6a5c6
Which compiler is right?
How can I write this code so both compilers accept it?
Both if constexpr and fold expressions would work in C++17, but this is a library header included by many projects, and not all of them are compiled with C++17. I need a solution which works in C++11.
Which compiler is right?
Clang is wrong in rejecting the code because the first overload candidate feh(Fn& fn, const std::tuple<H>*) should be preferred over the other candidate feh(Fn& fn, const std::tuple<H, R...>*) since the former is more specialized than the latter.
In other words, the version without the pack is considered more specialized and hence should be preferred if it matches the call.
This is because, basically(roughly) for one function template to be considered more specialized than the other, the latter should be able to accept all the template arguments that the former can accept but not vice-versa.
Now, in your given example the overload feh(Fn& fn, const std::tuple<H, R...>*) can accept(or work with) all template arguments which the former feh(Fn& fn, const std::tuple<H>*) can accept but the reverse is not true. Hence the former is more specialized than the latter. For more technical details of this process, refer to What is the partial ordering procedure in template deduction or from [temp.deduct.partial]/10 which states:
Function template F is at least as specialized as function template G if, for each pair of types used to determine the ordering, the type from F is at least as specialized as the type from G. F is more specialized than G if F is at least as specialized as G and G is not at least as specialized as F.
(emphasis mine)
clang++ is correct because both functions matches equally good. I'm unsure which compiler that is correct, but...
A C++11 solution could be to just add the requirement that the Rest part must contain at least one type and that is easily done by just adding R1. That would mean that the rest of your code could be left unchanged:
template<typename Fn, typename H, typename R1, typename... R>
inline
void feh(Fn& fn, const std::tuple<H, R1, R...>*)
{
fn(H{});
using Rest = const std::tuple<R1, R...>*;
feh<Fn, R1, R...>(fn, static_cast<Rest>(nullptr));
}
A C++17 solution would be to remove the other feh overloads and use a fold expression:
template <typename Fn, typename... H>
inline void feh(Fn& fn, const std::tuple<H...>*) {
(..., fn(H{}));
}
This is a unary left fold over the comma operator which "unfolded" becomes:
(((fn(H1{}), fn(H2{})), ...), fn(Hn{}))
By far the simplest solution is an if constexpr :
template<typename Fn, typename H, typename... R>
inline
void feh(Fn& fn, const std::tuple<H, R...>*)
{
fn(H{});
if constexpr (sizeof...(R) > 0) {
using Rest = const std::tuple<R...>*;
feh<Fn, R...>(fn, static_cast<Rest>(nullptr));
}
}
and just remove the problematic overload.
How can I write this code so both compilers accept it?
You can write your code without recursion
template<typename Fn, typename ... Ts>
void fe(Fn& fn, const std::tuple<Ts...>* = nullptr)
{
// Trick to simulate fold expression of c++17
const int dummy[] = {0, (static_cast<void>(fn(Ts{})), 0)...};
static_cast<void>(dummy); // Avoid warning about unused variable
}
Which would become, in C++17
template<typename Fn, typename ... Ts>
void fe(Fn& fn, const std::tuple<Ts...>* = nullptr)
{
(static_cast<void>(fn(Ts{})), ...);
// static_cast is here to handle evil overloaded operator comma (for type returned by Fn)
// might be omitted if you know you are not in that pathological case
}
[Demo](fe(r, &tup);)
Recently I do a research about modern c++. I saw a video [in 49:00] about c++11/c++14 variadic templates. If you want to calculate the sum of tuple ofdifferent types(such as int, double) with variadic templates, using c++11, the video suggest a solution:
struct Sum
{
template<typename T>
static T sum(T n)
{
return n;
}
template<typename T, typename... Args>
static auto sum(T n, Args... rest) -> decltype(n+sum(rest...))
{
return n + sum(rest...);
}
}
auto x = Sum::sum(1, 2.5, 3);
auto can not deduce return type in c++11, so you have to declare return type using decltype. But some compiler build failed, some compiler build successfully.link
Although, using auto to deduce return type has no problem, my question is:
Has c++11 standard covered this question? If not, do the compilers deal with the problem by its own implementation?
Why do the newest version gcc 8.1 compile failed, whereas gcc 4/5/6/7 compile successfully? Is there any compatibility problem in gcc?
By the way, the compile error message is:
test.cc:20:16: error: no matching function for call to 'sum'
double x = Sum::sum(1, 2.5, 3);
test.cc:12:17: note: candidate template ignored: substitution failure [with T = int, Args = ]: use of undeclared identifier 'sum'
static auto sum(T n, Args... rest) -> decltype(n + sum(rest...))
test.cc:6:14: note: candidate function template not viable: requires
single argument 'n', but 3 arguments were provided
static T sum(T n)
1 error generated.
The function-name lookup in the trailing return type here,
template<typename T, typename... Args>
static auto sum(T n, Args... rest) -> decltype(n+sum(rest...))
is done in the context of immediately before this sum is declared, plus via ADL (argument dependent lookup).
And as this template is not visible via ADL at the point of invocation on the types in question, it is proper for this to fail to compile.
The older gcc compilers probably used the object context in addition to the contexts they are supposed to. That is a reasonable error to make.
You can fix this easily:
struct Sum {
private:
template<typename T>
friend T summer(Sum, T n) {
return n;
}
template<typename T, typename... Args>
friend auto summer(Sum, T n, Args... rest) -> decltype(n+summer(Sum{},rest...)) {
return n + summer(Sum{},rest...);
}
public:
template<class...Args>
auto sum(Args...args)->decltype(summer(Sum{}, args...)){
return summer(Sum{}, args... );
}
};
here we force ADL in some private friends. This permits the overloads of summer to "see themselves" in their trailing return type.
I'm trying to create template functor, which will take as arguments object and member function with any number of parameters. I can't figure out how to write the code correctly with templates.
template<typename ItemT,
class T,
typename ...Args>
struct Builder
{
ItemT operator()(T& object, ItemT (T::*method)(Args...), Args && ... args)
{
return (object.*method)(std::forward<Args>(args)...);
}
};
struct Object
{
int method(int, int, int) { return 4; }
};
int main()
{
Object obj;
Builder<int, Object>()(obj, &Object::method); // Error here
}
If I make Object::method with no parameters - code compiles. But with parameters - no.
Severity Code Description Project File Line Suppression State
Error C2664 'int Builder::operator ()(T &,ItemT (__thiscall Object::* )(void))': cannot convert argument 2 from 'int (__thiscall Object::* )(int,int,int)' to 'int (__thiscall Object::* )(void)' drafts c:\drafts\main.cpp 139
Assuming you don't want to change the current definition of Builder, this is how you need to instantiate it:
Builder<int, Object, int, int, int>()(obj, &Object::method, 0, 0, 0);
// ^ ^ ^^^^^^^^^^^^^ ^^^^^^^
// ItemT | | |
// T Args... args...
The args... parameter expansion in the operator() call must match the TArgs... pack passed to Builder itself.
wandbox example
Here's an alternative less strict design:
template<typename T>
struct Builder
{
template <typename TFnPtr, typename... Args>
auto operator()(T& object, TFnPtr method, Args && ... args)
{
return (object.*method)(std::forward<Args>(args)...);
}
};
The above Builder can be used like this:
int main()
{
Object obj;
Builder<Object>()(obj, &Object::method, 0, 0, 0);
}
In this case the type of member function pointer is deduced through TFnPtr and not constrained to any particular set of parameters. The variadic parameters are not part of Builder anymore - they're part of Builder::operator(), so they can be deduced and forwarded to (object.*method).
wandbox example
You can avoid templating on Builder altogether and solely rely on template argument deduction:
struct Builder {
template <typename Obj, typename R, typename ... FArgs, typename ... Args>
R operator()(Obj& obj, R (Obj::*fn)(FArgs...), Args&&... args) {
return (obj.*fn)(std::forward<Args>(args)...);
}
};
I chose to use two parameter packs to allow perfect forwarding: the value categories of the operator() call do not necessarily match the targeted method. This also allows for implicit conversion of arguments when applying the member function pointer. Note that this implementation will not match const methods of Obj.
You can of course relax it a bit using auto return type (C++14) or trailing return type (C++11). Since Vittorio's answer already presented you the C++14 way, I'll tackle the latter. The operator() then becomes:
template <typename Obj, typename FnPtr, typename ... Args>
auto operator()(Obj& obj, FnPtr fn, Args&&... args)
-> decltype((obj.*fn)(std::forward<Args>(args)...)) {
return (obj.*fn)(std::forward<Args>(args)...);
}
Then, usage will simply be:
Object obj;
Builder()(obj, &Object::method, 0, 0, 0);
live demo on Coliru.
Given the following code(taken from here):
#include <cstddef>
#include <type_traits>
#include <tuple>
#include <iostream>
#include <utility>
#include <functional>
template<typename ... Fs>
struct compose_impl
{
compose_impl(Fs&& ... fs) : functionTuple(std::forward_as_tuple(fs ...)) {}
template<size_t N, typename ... Ts>
auto apply(std::integral_constant<size_t, N>, Ts&& ... ts) const
{
return apply(std::integral_constant<size_t, N - 1>(), std::get<N> (functionTuple)(std::forward<Ts>(ts)...));
}
template<typename ... Ts>
auto apply(std::integral_constant<size_t, 0>, Ts&& ... ts) const
{
return std::get<0>(functionTuple)(std::forward<Ts>(ts)...);
}
template<typename ... Ts>
auto operator()(Ts&& ... ts) const
{
return apply(std::integral_constant<size_t, sizeof ... (Fs) - 1>(), std::forward<Ts>(ts)...);
}
std::tuple<Fs ...> functionTuple;
};
template<typename ... Fs>
auto compose(Fs&& ... fs)
{
return compose_impl<Fs ...>(std::forward<Fs>(fs) ...);
}
int main ()
{
auto f1 = [](std::pair<double,double> p) {return p.first + p.second; };
auto f2 = [](double x) {return std::make_pair(x, x + 1.0); };
auto f3 = [](double x, double y) {return x*y; };
auto g = compose(f1, f2, f3);
std::cout << g(2.0, 3.0) << std::endl; //prints '13', evaluated as (2*3) + ((2*3)+1)
return 0;
}
The code above works in C++14. I'm having some trouble making it work for C++11. I tried to properly provide the return types for the function templates involved but without much success e.g.:
template<typename... Fs>
struct compose_impl
{
compose_impl(Fs&&... fs) : func_tup(std::forward_as_tuple(fs...)) {}
template<size_t N, typename... Ts>
auto apply(std::integral_constant<size_t, N>, Ts&&... ts) const -> decltype(std::declval<typename std::tuple_element<N, std::tuple<Fs...>>::type>()(std::forward<Ts>(ts)...))
// -- option 2. decltype(apply(std::integral_constant<size_t, N - 1>(), std::declval<typename std::tuple_element<N, std::tuple<Fs...>>::type>()(std::forward<Ts>(ts)...)))
{
return apply(std::integral_constant<size_t, N - 1>(), std::get<N>(func_tup)(std::forward<Ts>(ts)...));
}
using func_type = typename std::tuple_element<0, std::tuple<Fs...>>::type;
template<typename... Ts>
auto apply(std::integral_constant<size_t, 0>, Ts&&... ts) const -> decltype(std::declval<func_type>()(std::forward<Ts>(ts)...))
{
return std::get<0>(func_tup)(std::forward<Ts>(ts)...);
}
template<typename... Ts>
auto operator()(Ts&&... ts) const -> decltype(std::declval<func_type>()(std::forward<Ts>(ts)...))
// -- option 2. decltype(apply(std::integral_constant<size_t, sizeof...(Fs) - 1>(), std::forward<Ts>(ts)...))
{
return apply(std::integral_constant<size_t, sizeof...(Fs) - 1>(), std::forward<Ts>(ts)...);
}
std::tuple<Fs...> func_tup;
};
template<typename... Fs>
auto compose(Fs&&... fs) -> decltype(compose_impl<Fs...>(std::forward<Fs>(fs)...))
{
return compose_impl<Fs...>(std::forward<Fs>(fs)...);
}
For the above clang(3.5.0) gives me the following error:
func_compose.cpp:79:18: error: no matching function for call to object of type 'compose_impl<(lambda at func_compose.cpp:65:15) &, (lambda at func_compose.cpp:67:15) &,
(lambda at func_compose.cpp:68:15) &>'
std::cout << g(2.0, 3.0) << std::endl; //prints '13', evaluated as (2*3) + ((2*3)+1)
^
func_compose.cpp:31:10: note: candidate template ignored: substitution failure [with Ts = <double, double>]: no matching function for call to object of type
'(lambda at func_compose.cpp:65:15)'
auto operator()(Ts&&... ts) /*const*/ -> decltype(std::declval<func_type>()(std::forward<Ts>(ts)...))
^ ~~~
1 error generated.
If I try "option 2." I get pretty much the same error.
Apart from the fact that it looks very verbose I also cannot seem to get it right. Could anyone provide some insight in what am I doing wrong?
Is there any simpler way to provide the return types?
The error message for your first option is due to the fact that in
std::declval<func_type>()(std::forward<Ts>(ts)...)
you're trying to call the f1 functor with two arguments of type double (the ones passed to operator()), but it takes a std::pair (func_type refers to the type of the first functor in the tuple).
Regarding option 2, the reason it doesn't compile is that the trailing return type is part of the function declarator and the function is not considered declared until the end of the declarator has been seen, so you can't use decltype(apply(...)) in the trailing return type of the first declaration of apply.
I'm sure you're now very happy to know why your code doesn't compile, but I guess you'd be even happier if you had a working solution.
I think there's an essential fact that needs to be clarified first: all specializations of the apply and operator() templates in compose_impl have the same return type - the return type of the first functor, f1 in this case.
There are several ways to get that type, but a quick hack is the following:
#include <cstddef>
#include <type_traits>
#include <tuple>
#include <iostream>
#include <utility>
#include <functional>
template<typename> struct ret_hlp;
template<typename F, typename R, typename... Args> struct ret_hlp<R (F::*)(Args...) const>
{
using type = R;
};
template<typename F, typename R, typename... Args> struct ret_hlp<R (F::*)(Args...)>
{
using type = R;
};
template<typename ... Fs>
struct compose_impl
{
compose_impl(Fs&& ... fs) : functionTuple(std::forward_as_tuple(fs ...)) {}
using f1_type = typename std::remove_reference<typename std::tuple_element<0, std::tuple<Fs...>>::type>::type;
using ret_type = typename ret_hlp<decltype(&f1_type::operator())>::type;
template<size_t N, typename ... Ts>
ret_type apply(std::integral_constant<size_t, N>, Ts&& ... ts) const
{
return apply(std::integral_constant<size_t, N - 1>(), std::get<N> (functionTuple)(std::forward<Ts>(ts)...));
}
template<typename ... Ts>
ret_type apply(std::integral_constant<size_t, 0>, Ts&& ... ts) const
{
return std::get<0>(functionTuple)(std::forward<Ts>(ts)...);
}
template<typename ... Ts>
ret_type operator()(Ts&& ... ts) const
{
return apply(std::integral_constant<size_t, sizeof ... (Fs) - 1>(), std::forward<Ts>(ts)...);
}
std::tuple<Fs ...> functionTuple;
};
template<typename ... Fs>
compose_impl<Fs ...> compose(Fs&& ... fs)
{
return compose_impl<Fs ...>(std::forward<Fs>(fs) ...);
}
int main ()
{
auto f1 = [](std::pair<double,double> p) {return p.first + p.second; };
auto f2 = [](double x) {return std::make_pair(x, x + 1.0); };
auto f3 = [](double x, double y) {return x*y; };
auto g = compose(f1, f2, f3);
std::cout << g(2.0, 3.0) << std::endl; //prints '13', evaluated as (2*3) + ((2*3)+1)
return 0;
}
Notes:
It compiles and works on GCC 4.9.1 and Clang 3.5.0 in C++11 mode, and on Visual C++ 2013.
As written, ret_hlp only handles function object types that declare their operator() similarly to lambda closure types, but it can be easily extended to pretty much anything else, including plain function types.
I tried to change the original code as little as possible; I think there's one important bit that needs to be mentioned regarding that code: if compose is given lvalue arguments (as in this example), functionTuple inside compose_impl will store references to those arguments. This means the original functors need to be available for as long as the composite functor is used, otherwise you'll have dangling references.
EDIT: Here's more info on the last note, as requested in the comment:
That behaviour is due to the way forwarding references work - the Fs&& ... function parameters of compose. If you have a function parameter of the form F&& for which template argument deduction is being done (as it is here), and an argument of type A is given for that parameter, then:
if the argument expression is an rvalue, F is deduced as A, and, when substituted back into the function parameter, it gives A&& (for example, this would happen if you passed a lambda expression directly as the argument to compose);
if the argument expression is an lvalue, F is deduced as A&, and, when substituted back into the function parameter, it gives A& &&, which yields A& according to the reference collapsing rules (this is what happens in the current example, as f1 and the others are lvalues).
So, in the current example, compose_impl will be instantiated using the deduced template arguments as something like (using invented names for lambda closure types)
compose_impl<lambda_1_type&, lambda_2_type&, lambda_3_type&>
which in turn will make functionTuple have the type
std::tuple<lambda_1_type&, lambda_2_type&, lambda_3_type&>
If you'd pass the lambda expressions directly as arguments to compose, then, according to the above, functionTuple will have the type
std::tuple<lambda_1_type, lambda_2_type, lambda_3_type>
So, only in the latter case will the tuple store copies of the function objects, making the composed function object type self-contained.
Now, it's not a question of whether this is good or bad; it's rather a question of what you want.
If you want the composed object to always be self-contained (store copies of the functors), then you need to get rid of those references. One way to do it here is to use std::decay, as it does more than remove references - it also handles function-to-pointer conversions, which comes in handy if you want to extend compose_impl to be able to also handle plain functions.
The easiest way is to change the declaration of functionTuple, as it's the only place where you care about references in the current implementation:
std::tuple<typename std::decay<Fs>::type ...> functionTuple;
The result is that the function objects will always be copied or moved inside the tuple, so the resulting composed function object can be used even after the original components have been destructed.
Wow, this got long; maybe you shouldn't have said 'elaborate' :-).
EDIT 2 for the second comment from the OP: Yes, the code as it is, without the std::decay (but extended to properly determine ret_type for plain function arguments, as you said) will handle plain functions, but be careful:
int f(int) { return 7; }
int main()
{
auto c1 = compose(&f, &f); //Stores pointers to function f.
auto c2 = compose(f, f); //Stores references to function f.
auto pf = f; //pf has type int(*)(int), but is an lvalue, as opposed to &f, which is an rvalue.
auto c3 = compose(pf, pf); //Stores references to pointer pf.
std::cout << std::is_same<decltype(c1.functionTuple), std::tuple<int(*)(int), int(*)(int)>>::value << '\n';
std::cout << std::is_same<decltype(c2.functionTuple), std::tuple<int(&)(int), int(&)(int)>>::value << '\n';
std::cout << std::is_same<decltype(c3.functionTuple), std::tuple<int(*&)(int), int(*&)(int)>>::value << '\n';
}
The behaviour of c3 is probably not what you want or what one would expect. Not to mention all these variants will likely confuse your code for determining ret_type.
With the std::decay in place, all three variants store pointers to function f.
I'm trying to write a simple function to convert a std::function<> object while binding the last parameter(s). That's what I've got:
template<typename R, typename Bind, typename ...Args> std::function<R (Args...)> bindParameter (std::function<R (Args..., Bind)> f, Bind b)
{
return [f, b] (Args... args) -> R { return f (args..., b); };
}
And that's how I'd like to use it:
int blub (int a, int b)
{
return a * b;
}
// ...
int main ()
{
std::function<int (int, int)> f1 (blub);
// doesn't work
std::function<int (int)> f2 = bindParameter (f1, 21);
// works
std::function<int (int)> f3 = bindParameter<int, int, int> (f1, 21);
return f2 (2);
}
... so that in this example the main function should return 42. The problem is, that gcc (4.6) doesn't seem to infer the types of the template parameters correctly, the first version produces the following errors:
test.cpp:35:58: error: no matching function for call to 'bindParameter(std::function<int(int, int)>&, int)'
test.cpp:35:58: note: candidate is:
test.cpp:21:82: note: template<class R, class Bind, class ... Args> std::function<R(Args ...)> bindParameter(std::function<R(Args ..., Bind)>, Bind)
But in my opinion the parameters are obvious. Or is this kind of type inference not covered by the standard or not yet implemented in gcc?
You can't use std::function as a deduced parameter of a function template. Deduction can't work in this fashion as there are no rules to match int(*)(int, int) to std::function<int(int, int)>. (Consider also that for any std::function<Signature> there is a constructor accepting int(*)(int, int), even if in most cases this results in an error when instantiated.)
It's problematic to detect the signature of functor in the general case. Even KennyTM's solution has limitations: it detects the signature of monomorphic functors and function-like things, but won't work for polymorphic functors (e.g. with overloaded operator()) or functors with surrogate call functions (even in the monomorphic case).
It is however possible to completely sidestep the issue of detecting the signature thanks to decltype (or equivalently, std::result_of), and I would recommend doing so. Hence, a variant on KennyTM's answer:
template<typename Functor, typename Bound>
struct bind_last_type {
Functor functor;
Bound bound;
template<typename... Args>
auto operator()(Args&&... args)
-> typename std::result_of<Functor&(Args..., Bound)>::type
// equivalent:
// -> decltype( functor(std::forward<Args>(args)..., std::move(bound)) )
{ return functor(std::forward<Args>(args)..., std::move(bound)); }
};
template<typename Functor, typename Bound>
bind_last_type<
typename std::decay<Functor>::type
, typename std::decay<Bound>::type
>
bind_last(Functor&& functor, Bound&& bound)
{ return { std::forward<Functor>(functor), std::forward<Bound>(bound) }; }
Not sure about the inference, but it works if I just define a templated function object.
template <typename FType, typename LastArgType>
struct BindLastHelper
{
FType _f;
LastArgType _last_arg;
template <typename... Args>
typename utils::function_traits<FType>::result_type
operator()(Args&&... args) const
{
return _f(std::forward<Args>(args)..., _last_arg);
}
};
template<typename FType, typename LastArgType>
BindLastHelper<FType, LastArgType> bindParameter (FType f, LastArgType b)
{
return BindLastHelper<FType, LastArgType>{f, b};
}
Note:
utils::function_traits is taken from https://github.com/kennytm/utils/blob/master/traits.hpp. std::result_of cannot be used because you are not passing a function pointer.
Proof of concept: http://ideone.com/ux7YY (here for simplicity I just redefined result_of.)