Closed stephenswat closed 5 months ago
Agreed the naming could be improved; I see a few functions that we could implement which would need a name:
The first two are implemented, I agree the second two could also be useful; but they need names.
Could be something like bulk_insert_implicit
, bulk_insert_implicit_unsafe
, bulk_insert
(with 2 overloads)?
As long as we're workshopping the names, I'd prefer bulk_append_implicit
, etc. Since these will only ever add new elements at the end of the vector.
I have renamed the functions and added the additional two functions I described above.
I think this should be good to go now. I'd suggest we get this and #275 in and tag a release.
Are you still tweaking it, or is it ready? 😕
This is now ready to go. :+1:
Good. Then let me just put some unit tests on top of it, which I invite you to check. 😉
Looks sane. :+1:
Let's finally get this in. :smile:
A very common pattern in massively parallel computing is to reserve space for an entire thread block at once and to insert those values later. This commit adds a
reserve
andreserve_unsafe
method todevice_vector
, which allows clients to do this.The semantics of
reserve
are fully compliant with the C++ standard starting from C++20; C++ standards below that will work just fine. Any program which calls this function and compiles should be well formed, as defined in P0593R6 and P2590R2.The
reserve_unsafe
method does the same, but technically leaves the program in an ill-defined state. Note that this form of ill-defined memory has been used for donkeys years and is actually safe. It's just technically not standards compliant.