Skip to content

[oneDPL] Add memory parallel range algorithms #631

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

dmitriy-sobolev
Copy link
Contributor

@dmitriy-sobolev dmitriy-sobolev commented Jul 20, 2025

Adding uninitialized_default_construct, uninitialized_value_construct, uninitialized_move, uninitialized_copy, uninitialized_fill and destroy parallel range algorithms into oneDPL specification.

@akukanov akukanov added the DPL label Jul 29, 2025
@dmitriy-sobolev dmitriy-sobolev force-pushed the add-range-memory-algorithms branch 2 times, most recently from 0dc211c to b69247a Compare August 5, 2025 21:36
@danhoeflinger danhoeflinger self-requested a review August 6, 2025 15:05
Copy link
Contributor

@rarutyun rarutyun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, looking at the new set of Parallel Range Algorithms I am pretty sure that either referring to the C++ working draft or adding execution-policy concept to our spec would simplify the signatures quite significantly...

using /*projected-value-type*/ = std::remove_cvref_t<std::invoke_result_t<Proj&, std::iter_value_t<I>&>>;
// C++20 analogue of nothrow-random-access-range proposed for C++26 in P3179R9; exposition only
template <typename R>
concept nothrow-random-access-range =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why did we decide to "copy" this concept instead of nothrow-sized-random-access-range?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for consistency with the other signatures, where sized_range comes under requires clauses.

@akukanov
Copy link
Contributor

akukanov commented Aug 18, 2025

Overall, looking at the new set of Parallel Range Algorithms I am pretty sure that either referring to the C++ working draft or adding execution-policy concept to our spec would simplify the signatures quite significantly...

We cannot reuse execution-policy from the draft, our policies do not satisfy it. We can think of adding a public concept for an execution policy into the specification. Maybe having a sized RA range concept would be useful too, and since C++26 makes it exposition-only we would not even duplicate the standard. Let's consider outside of this PR though.

@dmitriy-sobolev dmitriy-sobolev force-pushed the add-range-memory-algorithms branch from ee35282 to 5d6a0d2 Compare August 19, 2025 21:14
Copy link
Contributor

@akukanov akukanov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks good to me now.

Co-authored-by: Alexey Kukanov <[email protected]>
Copy link
Contributor

@danhoeflinger danhoeflinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@akukanov akukanov merged commit c64b530 into uxlfoundation:main Aug 22, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants