-
Notifications
You must be signed in to change notification settings - Fork 108
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
[oneDPL] Add parallel range algorithms #569
base: main
Are you sure you want to change the base?
Conversation
eb3db22
to
520e688
Compare
source/elements/oneDPL/source/parallel_api/parallel_range_api.rst
Outdated
Show resolved
Hide resolved
compiled for earlier editions of the standard. | ||
|
||
The parallel range algorithms reside in ``namespace oneapi::dpl::ranges``. Same as the range algorithm functions | ||
defined by the `C++ standard` in ``namespace std::ranges``, they cannot be found by argument-dependent name lookup. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want just require (on the specification level) that all of them are global callable objects (independently of where C++ standard goes)? With that requirement we give extra benefits for the users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which specifically benefits would that give? Not theoretical but real ones, something that you can imagine being useful in practice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
passing algorithms as arguments to a function. This is the only practical difference I can see. It's guaranteed to work. With having "special function that..." it's not guaranteed to work. That's it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's a possibility. But I do not know why one would use it in practice, given that calling signatures of those algorithms are quite different and there seems no obvious reason why this would be useful.
In simple words, I see practical value of this being (nearly) absent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added a note about function object based implementations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
The specification for oneDPL parallel range algorithms.
oneDPL RFC discussion: oneapi-src/oneDPL#1741
Tagging @rarutyun @MikeDvorskiy