-
Notifications
You must be signed in to change notification settings - Fork 110
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
Extend parallel_reduce named requirements to allow rvalue reduction #595
base: main
Are you sure you want to change the base?
Conversation
.. cpp:function:: Value Func::operator()(const Range& range, const Value& x) const | ||
|
||
Accumulates result for a subrange, starting with initial value ``x``. | ||
``Range`` type must meet the :doc:`Range requirements <range>`. | ||
``Value`` type must be the same as a corresponding template parameter for the | ||
:doc:`parallel_reduce algorithm <../../algorithms/functions/parallel_reduce_func>` algorithm. | ||
|
||
If both variations are provided, the implementation should prefer the first form. |
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.
This is not fully clear to me. In which sense an implementation should prefer one form over the other? Are there certain conditions for when each form can/should be used? What happens if an implementation does not follow this advice?
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, I also thought about this when moving it into the spec. As I see, the only thing is that the implementation should allow both variations in isolation and it it is unclear what should general implementation do when both of them are provided. Our TBB implementation always passes Value
as rvalue that results in preferring the first form.
Other implementation can prefer an other approach and we don't know how tricky it can be. Now I feel like it would be better to state that in case of providing both forms, the behavior is implementation-defined.
In this case, should we ideally state the exact behavior in oneTBB documentation?
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 wonder if this difference is / should be covered by how we describe pseudo-signatures:
bool operator<(const T &x, const T &y)
A real signature may differ from the pseudo-signature that it implements in ways where implicit conversions would deal with the difference. For an example type U, the real signature that implements operator< in the table above can be expressed asint operator<( U x, U y )
, because C++ permits implicit conversion from int to bool, and implicit conversion from U to (const U&). Similarly, the real signaturebool operator<( U& x, U& y )
is acceptable because C++ permits implicit addition of a const qualifier to a reference type.
Essentially, a pseudo-signature in a named requirement describes the intended use of types by the library. Perhaps this should be updated for C++11 so that the difference between rvalues and lvalues is taken into account.
Extend
PararallelReduceFunc
andParallelReduceReduction
to allow user callable objects accepting rvalues.