-
Notifications
You must be signed in to change notification settings - Fork 41
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
Remove requirement on knowing geometry types in IndexableGetter #1211
base: master
Are you sure you want to change the base?
Conversation
typename Enable = std::enable_if_t< | ||
!Details::is_pair_value_index_v<std::decay_t<Geometry>>>> |
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 needed so that universal reference does not grab PairValueIndex
specializations.
KOKKOS_FUNCTION Value operator()(PairValueIndex<Value, Index> &&pair) const | ||
template <typename Geometry, typename Index> | ||
KOKKOS_FUNCTION Geometry | ||
operator()(PairValueIndex<Geometry, Index> &&pair) const | ||
{ | ||
return pair.value; |
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.
Shouldn't we be moving it and returning a && here?
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'm not sure why you are asking. We return a struct member. We don't need to do anything with the parent.
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 suppose we don't care since we get guaranteed copy elision?
Co-authored-by: Damien L-G <[email protected]>
3c34dfb
to
6ffdcf2
Compare
Couple irrelevant build failures (out of space, gpu not picked up). |
In the current iteration, if a user has a custom geometry type that they try to build hierarchy on, it has to be tagged with one of the ArborX tags, which would call ArborX routines. This patch relaxes this requirement. Now, a user only needs to specify dimension and coordinate type.
I added a compile-only test that shows the requirements.