-
Notifications
You must be signed in to change notification settings - Fork 49
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
core(view): warn about the implications of without initializing #569
core(view): warn about the implications of without initializing #569
Conversation
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.
Please do not mix the change of format with editing the actual content in the same PR
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.
Please split this pull request up. Either add the changes to initialization first or convert the file first. Also adding another flag in doc/Makefile
should be a separate pull request.
f8fac61
to
b5748d0
Compare
b5748d0
to
aaed3a0
Compare
For instance, if you need the destructor of your :code:`MyObjectWithDestructor` be called for each element of your :cppkokkos:`View<MyObjectWithDestructor*>`, | ||
you **should not use** :cppkokkos:`WithoutInitialization`. |
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.
For instance, if you need the destructor of your :code:`MyObjectWithDestructor` be called for each element of your :cppkokkos:`View<MyObjectWithDestructor*>`, | |
you **should not use** :cppkokkos:`WithoutInitialization`. | |
For instance, if the View's value type is not trivially destructible, | |
you **should not use** :cppkokkos:`WithoutInitialization` unless you are taking care of calling the destructor manually before the View deallocates its memory. |
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.
Much better indeed.
The reason for that is, since `Kokkos` did not initialize the memory, it cannot know onto which elements of the :cppkokkos:`View` calling the destructor | ||
of the :code:`value_type` is valid. |
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.
Maybe, rather something like
The reason for that is, since `Kokkos` did not initialize the memory, it cannot know onto which elements of the :cppkokkos:`View` calling the destructor | |
of the :code:`value_type` is valid. | |
The mental model is that whenever placement new is used to call the constructor, the destructor also isn't called before the memory is deallocated but it needs to be be called manually. |
Or omit it with my previous suggestion.
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.
✔️
aaed3a0
to
b421355
Compare
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.
Good instinct to improve this documentation. Cleaning up the WithoutInitialization
section is the more actionable suggestion. My comment about "novice" is one for broader consideration.
For instance, if the :cppkokkos:`View`'s value type is not trivially destructible, | ||
you **should not use** :cppkokkos:`WithoutInitialization` unless you are taking care of calling the destructor manually before the :cppkokkos:`View` deallocates its memory. | ||
|
||
The mental model is that whenever placement new is used to call the constructor, the destructor also isn't called before the memory is deallocated but it needs to be called manually. |
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.
Suggestion: maybe spell out what to do in the case of both trivially and non-trivially destructible data types, maybe even including a couple of simple code-snippet examples. Perhaps also mention a couple of typical use cases where someone would want to use a View WithoutInitialization
.
The sentence on line 469 is not clear, and is a little redundant with the immediately preceding statements. It may not be necessary if the previous verbiage were sharpened up, with spelled out use cases and an couple of simple examples.
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 think this is sufficient. I you don't understand the difference between trivially destructible and not trivially destructible you should not use View of Views - i.e. you are a novice
and should have skipped this section.
This PR describes what
Kokkos::WithoutInitialization
implies.