Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
hpx::is_trivially_relocatable trait implementation #6264
hpx::is_trivially_relocatable trait implementation #6264
Changes from 19 commits
1f88873
a179c52
c435377
9f2c184
1db200e
c8ff8dc
0603265
0b46dd6
f63342b
442972a
76dcad2
4221069
1b39238
689a1fc
c2acd4f
6caee74
863e5a6
5e7bb7a
9e1d723
89cf296
24a1890
e6d0384
8e39def
170b8df
c7d3639
347cacb
7139cb1
3b626c4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
last minute thought: adding static_assert(is_relocatable) ; as it is impossible to be trivially_relocatable but not relocatable.
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.
That's what I thought as of P1144R6; but the current revision (P1144R8) adopts the viewpoint that "trivially relocatable" is like "trivially copyable." It implies, "I promise that hypothetically when you (copy|relocate|compare) this thing, you can do it trivially." It doesn't imply anything about whether it is actually okay to (copy|relocate|compare) the thing; that's up to the algorithm's author to check.
E.g.
...however, I see that I need to update my libc++ implementation to actually reject the latter. ;)
Anyway, I don't have a strong opinion on which way HPX should define their trait. If you want to make it false for non-relocatable types, that's not crazy; it won't explode or anything. But I did want to point out that P1144R8 chooses to do it differently, and why P1144R8 chooses to do it differently.
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 see, I am struggling to think of a case where using std::relocate on a trivially relocatable but not relocatable type would be correct. I think I must be missing something
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.
That's the point: it'd never be correct. And neither would it be correct to use
std::copy
on a trivially copyable but not copy-assignable type. That doesn't mean such a type is not trivially copyable (or not trivially relocatable); it just means that you can't use it with those algorithms because they require copy-assignability resp. relocatability.The interface constraint on
std::copy
is that the type you pass in needs to beis_copy_assignable
. Internally, the optimization into a memcpy kicks in when the type happens to beis_trivially_copyable
.The interface constraint on
std::uninitialized_relocate
is that the type you pass in needs to beis_relocatable
. Internally, the optimization into a memcpy kicks in when the type happens to beis_trivially_relocatable
.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.
Ohhh I see, so it's just a matter of where this check should be performed, R8 suggests it should not throw a compile error when you give a non-relocatable type this trait, but it should when we try to relocate it, right? And this is checked with a static assertion inside the relocation algorithms
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 believe you've got it now. Here's a concrete example with libc++: https://godbolt.org/z/Yr9MdncoT
If you could relocate
S
, then you could do so trivially. But in fact you can't relocateS
.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.
| If you could relocate
S
, then you could do so trivially. But in fact you can't relocateS
.Just for a sanity check; arrays of trivially relocatable types
T[]
should be considered trivially relocatable, but not relocatable (as not move constructable)?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, that's exactly right. https://godbolt.org/z/9n4YGTjfd (P1144R8 has actually removed
std::is_relocatable_v
, but keptstd::relocatable
. My Godbolt implementation keeps both, at least for now, since they're trivial to implement.)