[oneDPL][rfc][ranges][L1] the third portion of the range based API #2269
Conversation
| The feature is proposed as the next step of range-based API support for oneDPL. | ||
|
|
||
| ### Key Requirements | ||
| - The range-based signatures for the mentioned API should correspond to the [proposed specification](https://github.com/uxlfoundation/oneAPI-spec/pull/614) |
There was a problem hiding this comment.
The specification should yet be updated; the link is to the previous patch.
| - The implementation is supposed to rely on existing range-based or iterator-based algorithm patterns, which are already | ||
| implemented in oneDPL. |
There was a problem hiding this comment.
Does it make sense to provide mapping of algorithms to the patterns, or is it always the same as for iterator-based overloads?
I am not trying to create extra work, but it would be good to make sure that no problems with the implementation are expected, since the proposed set is quite big,
There was a problem hiding this comment.
- For hetero impl - it is based on existing range based algo patterns.
- For host impl - it is based on existing iterator based algo patterns +
std::ranges::begin, std::ranges::begin(..) + std::ranges::size(); - The "output size limit semantic" is on high level layer before call an algo pattern or a corresponding algo pattern has a few changes to support output size limit.
| - Several algorithms described in P3179 have slightly different semantics. To implement these, some existing algorithm patterns | ||
| might require modifications or new versions. |
There was a problem hiding this comment.
Perhaps this can be a bit more specific on both the patterns and the changes needed.
There was a problem hiding this comment.
Actually, this sentence is not relevant now and in this context and should be removed.
| - For the algorithms, which work with uninitialized memory (`uninitialized_*` and `destroy` form `<memory>`) an additional require is proposed: `oneapi:dpl::value_adressable`. | ||
| The require can be implemented via C++ concept: `template<typename R> concept value_adressable = requires { std::addressof(*std::ranges::iterator_t<R>{}); };` |
There was a problem hiding this comment.
It would be good to explain potential benefits of this idea.
There was a problem hiding this comment.
It looks like the "nothrow" requirements for iterators/ranges used with uninitialized_* algorithms (https://en.cppreference.com/w/cpp/memory/ranges/nothrow_concepts.html) effectively cover the addressability.
template< class I >
concept no-throw-input-iterator =
std::input_iterator<I> &&
std::is_lvalue_reference_v<std::iter_reference_t<I>> &&
std::same_as<std::remove_cvref_t<std::iter_reference_t<I>>, std::iter_value_t<I>>;
This concept requires that the result of dereferencing (std::iter_reference_t<I>) is an lvalue reference to the iterator value type.
There was a problem hiding this comment.
yes, it looks that no-throw-input-iterator is sufficient.
| ## Motivations | ||
| The feature is proposed as the next step of range-based API support for oneDPL. | ||
|
|
||
| ### Key Requirements |
There was a problem hiding this comment.
Let's add the feature testing macro update to the requirements, so that it is not forgotten again.
[oneDPL][rfc][ranges][L1] the third portion of the range based API