Skip to content
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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

kboyarinov
Copy link
Contributor

Extend PararallelReduceFunc and ParallelReduceReduction to allow user callable objects accepting rvalues.

.. 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.
Copy link
Contributor

@akukanov akukanov Oct 10, 2024

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?

Copy link
Contributor Author

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?

Copy link
Contributor

@akukanov akukanov Oct 11, 2024

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 as int 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 signature bool 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.

@akukanov akukanov marked this pull request as draft November 5, 2024 22:21
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.

2 participants