-
Notifications
You must be signed in to change notification settings - Fork 115
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] oneDPL '__future' class code cleanup and API fix #1962
Conversation
auto | ||
get() | ||
get(std::size_t __idx = 0) |
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.
Everybody who will take a look at this function will ask - what is template param and run-time param here,
Explanation required, I think.
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.
The bullets 1 and 2 #1962 (comment) explain it.
Yes, probably it make sense to write a comment in the code.
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.
Better to understand this from code...
@@ -701,31 +701,42 @@ struct __deferrable_mode | |||
{ | |||
}; | |||
|
|||
//A contract for future class: <sycl::event or other event, a value, sycl::buffers..., or __usm_host_or_buffer_storage> | |||
//Impl details: inheritance (private) instead of aggregation for enabling the empty base optimization. | |||
// An overload of __wait_and_get_value for 'sycl::buffer' |
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.
Can we modify these function without move them outside?
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.
The change also solves a code coupling
issue.
There was a code coupling
between following types: __future, 'sycl::buffer', '__result_and_scratch_storage'.
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.
But why should move them outside of class __future
?
Let's still use them as class-member functions, why not?
56968d6
to
065b75d
Compare
065b75d
to
8232c73
Compare
e1e50e3
to
07fd3f8
Compare
In general, the the change doesn't solve a use case when we need to return/get a couple of values from a future objects. |
A little bit refactoring and class API fix for oneDPL
future
type.__future
instance via__future::get
method.__future
instance via__future::get
method.code coupling
between following types:__future
, 'sycl::buffer', '__result_and_scratch_storage'The PR fixes the 1,2,3 mentioned issues.