Andrea Bocci
Thinking about it: - an explicitly invalid state would also be OK for our use case: ```c++ // instantiate a buffer in an empty and invalid state auto buffer =...
In fact, Alpaka objects do have an "empty, invalid state" - the "moved from" state: ```c++ #include #include int main(void) { using Idx = uint32_t; using Host = alpaka::DevCpu; using...
> The "invalid" state after a move is not really such: one should not use an object after it has been moved from, because its state is more undefined than...
Sorry, but I don't buy your argument. Saying that a Buffer object is never invalid - except when it is invalid because it was moved from - so there is...
So, to me this boils down to one of 1. enforcing that an Event or Queue or Buffer is _always_ valid: either by disallowing moving them (incurs in a small...
> objects should not be used after being moved from. However, objects should be safe to be used after being default constructed, if such a construction is possible. Well, this...
> It may also be worth noting that the Microsoft standard library developers recommend using `std::optional` for the use case presented in the initial issue comment: [Source](https://devblogs.microsoft.com/cppblog/stdoptional-how-when-and-why/#the-need-for-not-yet-a-thing). Funny that they...
> > Well, this is not an argument, it's an arbitrary assertion. > > It's not an argument in a scientific sense, but it's not arbitrary either. It's design consensus...
Does it make any difference if you pass `sizeElems` by value instead of by `const&` ?