Re: Failure to deduce template argument to std::function from lambda
On 2012-03-22 01:26, Andy Champ wrote:
[..]
There are basically two ways to make this work. I'm starting with that
one, which demonstrates the root of your problem here. It bases on an
idiom to make the parameter Item non-deducible in
std::function<void(Item&)>. Just define
template<class T>
struct identity { typedef T type; };
and rewrite for_each_in to:
template <typename Item>
void for_each_in(
std::vector<Item>& vec,
std::function<void(typename identity<Item>::type&)> functor)
{
std::for_each(vec.begin(), vec.end(), functor);
}
OK, I see. it's taken me a couple of minutes though. I think I'd have
trouble in the code review. it's also putting a new type "identity" into
the namespace, which I'd prefer to avoid - but that name is completely
arbitrary, so can be as mangled as I like.
This is correct. In theory I could have used std::common_type<T> instead
of identity, for example. Personally I find the simpler template
identity used in this idiom easier to understand.
It may be worth to consider to standardize the following as a useful
C++11 idiom taking advantage of an alias template:
template<class T>
using non_deduced = typename identity<T>::type;
and then using only the alias in your declarations:
template <typename Item>
void for_each_in(std::vector<Item>& vec,
std::function<void(non_deduced<Item>&)> functor);
This looks pretty much readable to me and is hopefully self-explaining.
A much simpler solution in your example is to give up the dependency to
std::function in for_each_in (From your code there is no obvious reason
for this) and to write instead:
template <typename Item, typename F>
void for_each_in(
std::vector<Item>& vec,
F functor)
{
std::for_each(vec.begin(), vec.end(), functor);
}
... and that's the way I think I'll end up doing it.
I think this removes any link between the types of F and of Item, beyond
that the type of the iterator's target is going to be compatible in some
way with the type of the parameter in the lambda, but I can live with
it. Experimentation shows me I had that problem anyway.
It is possible to combine the advantages of both worlds by making your
second for a constrained template. First introduce a reusable trait
is_callable e.g. like so:
#include <type_traits>
template<class T>
typename std::add_rvalue_reference<T>::type declval();
// Unless I'm mistaken, VC10 does not provide std::declval as it should
template<class F, class Arg>
struct is_callable_impl {
template<class F2, class Arg2>
static auto test(int) -> decltype((void)
declval<F2>()(declval<Arg2>()), std::true_type());
template<class, class>
static auto test(...) -> std::false_type;
typedef decltype(test<F, Arg>(0)) type;
};
template<class F, class Arg>
struct is_callable : is_callable_impl<F, Arg>::type {};
After this declare your template as follows:
template <typename Item, typename F>
typename std::enable_if<is_callable<F&, Item&>::value>::type
for_each_in_3(std::vector<Item>& vec, F functor);
Now tell me - is half past four the normal time you start work in Germany?
No.
HTH & Greetings from Bremen,
Daniel Kr??gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]