std::input_iterator and ranges::input_range as the prospective API. What would the benefit be on parallelizing the ranges algorithms if the supported iterator was just an
InputIt? AFAIAC you cannot impose parallelization without a RandomAccessIterator.
std::execution::seq but your comment suggest that you wanted to use
std::execution::par on the last line. Is that correct? |
#Boost #Cpp #CppNow Slides: https://cppnow.org/history/2021/talks/ CppNow Website: https://cppnow.org CppNow Twitter: @CppNow Streamed \u0026 Edited By Digital Medium Ltd: https://events.digital-medium.co.uk ------ Ranges have recently been introduced to the
realm of C++ Standard. While the initiating idea was to increase the level of ...
www.youtube.com
|
|
The C++ Standard Library for Parallelism and Concurrency - hpx/libs/core/algorithms/include/hpx/parallel/container_algorithms at master · STEllAR-GROUP/hpx
github.com
|
template< class ExecutionPolicy, std::input_iterator I, std::sentinel_for<I> S, class Proj = std::identity, std::indirectly_unary_invocable<std::projected<I, Proj>> Fun > requires (std::is_execution_policy_v<std::remove_cvref_t<ExecutionPolicy>>) constexpr for_each_result<I, Fun> for_each( ExecutionPolicy&& policy, I first, S last, Fun f, Proj proj = {} ); template< class ExecutionPolicy, ranges::input_range R, class Proj = std::identity, std::indirectly_unary_invocable<std::projected<ranges::iterator_t<R>, Proj>> Fun > requires (std::is_execution_policy_v<std::remove_cvref_t<ExecutionPolicy>>) constexpr for_each_result<ranges::borrowed_iterator_t<R>, Fun> for_each( ExecutionPolicy&& policy, R&& r, Fun f, Proj proj = {} );