[PATCH] D33997: Implement the non-execution policy versions of `reduce` and `transform_reduce` for C++17

Bryce Adelstein Lelbach via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jun 8 15:06:37 PDT 2017


wash added a comment.

For all the `transform_` variants, the spec allows the "inner" operation (the transformation)'s return type is not constrained. We should have a test for this.

For example, consider the binary-unary `transform_reduce` implementation:

  template <class _InputIterator, class _Tp, class _BinaryOp, class _UnaryOp>
  inline _LIBCPP_INLINE_VISIBILITY
  _Tp
  transform_reduce(_InputIterator __first, _InputIterator __last, 
                   _Tp __init,  _BinaryOp __b, _UnaryOp __u)
  {
      for (; __first != __last; ++__first)
          __init = __b(__init, __u(*__first));
      return __init;
  }

The standard says the algorithm requires all of the following expressions be convertible to `_Tp`:

- `__b(__init, __init)`
- `__b(__init, __u(*__first))`
- `__b(__u(*__first), __init)`
- `__b(__u(*__first), __u(*__first))`

So, the following code should be allowed:

  struct A {};
  struct B {};
  struct C {};
  
  B unary_op(C);
  A binary_op(A, A);
  A binary_op(A, B);
  A binary_op(B, A);
  A binary_op(B, B); 
  
  std::vector<C> v;
  std::tranform_reduce(v.begin(), v.end(), A{}, binary_op, unary_op);

Similar cases can be constructed for all the other `transform_` overloads.

I'll try to find time later to put together a concrete test for this.


https://reviews.llvm.org/D33997





More information about the cfe-commits mailing list