make unary_function/binary_function optional (C++11)

[andrewcorrigan]

This is intended for the C++11 milestone:

Can requiring that unary_function and binary_function be the base class for a UnaryFunction or BinaryFunction in Thrust algorithms be made optional?

Not only does this remove the need for deriving from these types, I think (I'm just now starting to really learn C++11) that it also removes the need for writing constructors for small functors since they can instead be instantiated with aggregate initialization once the functors would no longer have a base class.

struct adds_a : public thrust::unary_function<int,int>
{
  int _a;
  adds_a(int a) : _a(a) {}
  int operator()(int i) const { return i + this->_a; }
};
...
adds_a(3);

becomes:

struct adds_a
{
  int _a;
  int operator()(int i) const { return i + this->_a; }
};
...
adds_a{3};

I've already made this change in my private copy of Thrust via std::result_of in thrust/detail/type_traits/result_of.h.

template<typename Signature>
  struct result_of
{
  typedef typename std::result_of<Signature>::type type;
};

[andrewcorrigan]

Would you be interested in pull requests that can non-invasively start making use of C++11?

#if __cplusplus >= 201103L    // or something like THRUST_USE_CXX11?
template<typename Signature>
  struct result_of
{
  typedef typename std::result_of<Signature>::type type;
};
#else
template<typename Signature, typename Enable = void> struct result_of;

// specialization for unary invocations of things which have result_type
template<typename Functor, typename Arg1>
  struct result_of<
    Functor(Arg1),
    typename thrust::detail::enable_if<thrust::detail::has_result_type<Functor>::value>::type
  >
{
  typedef typename Functor::result_type type;
}; // end result_of
#endif
// specialization for binary invocations of things which have result_type
template<typename Functor, typename Arg1, typename Arg2>
  struct result_of<
    Functor(Arg1,Arg2),
    typename thrust::detail::enable_if<thrust::detail::has_result_type<Functor>::value>::type
  >
{
  typedef typename Functor::result_type type;
};
#endif

[schiller-manuel]

@jaredhoberock How is your plan to continue the development Thrust with C+11 support?

[schiller-manuel]

This would really help when using templated functors in combination with zip iterators, e.g:

template <typename Tuple>
struct Fun : public thrust::unary_function<Tuple, Tuple>
{
    __host__ __device__
    Tuple operator()(Tuple p)
    {
        return p;
    }
};

thrust::device_vector<int> v1(10);
thrust::device_vector<int> v2(10);
auto zip_begin = thrust::make_zip_iterator(thrust::make_tuple(v1.begin(), v2.begin()));

typedef ... TupleType; // what is the exact type of the tuple? 
auto transform_it_begin = thrust::make_transform_iterator(zip_begin, Fun<TupleType>());

If thrust::unary_function was not needed, I could simply write:

struct Fun
{
    template <typename Tuple>
    __host__ __device__
    Tuple operator()(Tuple p)
    {
        return p;
    }
};

// ...
auto transform_it_begin = thrust::make_transform_iterator(zip_begin, Fun());

[jaredhoberock]

If you guys want to work out a pull request for this one, I'll review and merge.

[schiller-manuel]

@jaredhoberock Would you like to have a global #define switch like THRUST_USE_CXX11 or just use __cplusplus >= 201103L ? This does not only apply here but is a general decision on how to handle c++11 features.

[jaredhoberock]

I'd prefer not introducing new switches. I assume if people are already opting into something like -std=c++11 through the compiler, they want to use C++11 throughout their project.

[schiller-manuel]

Would c++11 support render thrust/detail/type_traits.h unnecessary and we could simply use <type_traits>?

[jaredhoberock]

There's a lot of non-standard stuff in thrust/detail/type_traits.h, so it needs to remain. If I understand @andrewcorrigan's earlier post, this feature shouldn't require anything beyond result_of, right?

[schiller-manuel]

Yes, it only uses std::result_of.

[schiller-manuel]

regarding __cplusplus:

I don't use Visual Studio, but it seems like that at least up to VS2013, __cplusplus is still 199711L (source). This means code using Thrust which relies on C++11 features being enabled through that macro won't compile in VS.

[jaredhoberock]

That's fine, I wouldn't want to rely on C++11 features unless that macro reported they were available.

[schiller-manuel]

Yet, these C++11 features are available on VS. In my platform independent project, I still have to derive from thrust::unary_function because my code will not compile otherwise in VS because this macro is still set erroneously to 199711L by VS.

I know it looks ugly, but how about using the aforementioned preprocessor switch THRUST_USE_CXX11 to enable Thrust's C++11 features instead of relying on __cplusplus >= 201103L? This switch can be automatically set when the compiler reports the correct version:

#ifndef THRUST_USE_CXX11
    #if __cplusplus >= 201103L
        #define  THRUST_USE_CXX11
   #endif
#endif

I could then globally define in my code:

#define THRUST_USE_CXX11

This would change nothing for GCC, but would enable Thrust's C++11 features for VS.

[jaredhoberock]

That's fine -- we needn't engage in heroics to enable this feature. VS2013 users can just use thrust::unary_function and upgrade to a newer compiler that reports that it supports C++11.