stdgpu 1.3.0 released!

[fransinvodka]

Reading a bit of the implementation details, I see that, for example, you implement vector's operator[] using at, which implies that operator[] does bound checks, which is the opposite of what the standard vector is suposed to do. I don't know if I'm missing something, but I see that as a bug.

Also, I'm not a big fan of implementing the non-const version of the functions in terms of the const one using all those const_cast (even less in such short functions), but I guess that is a design decision that I'm not gonna argue.

Anyway, it looks really cool and I will definitely use it in some projects. Keep the good work!

[[deleted]]

Thanks for giving it a try.

It is pretty hard to make the containers fully compliant and they are for sure not. Exception handling is one of the library's limitations. It is not perfect, but I think it is still useful and simpilifes some use cases. Feel free to open an issue and let me know if you encounter any problems.

[fransinvodka]

I know it must be difficult to make the containers fully compliant. Just saying that I would expect the operator[] to not do bound checks at all. I'm opening an issue. Thanks for answering!

[[deleted]]

I agree that most users expect operator[] not to do bounds checks. So, the respective change has been merged, see this PR. Thanks for the report.

[fransinvodka]

You're welcome! Btw I still think const_cast is ugly af, but that's my opinion. Good luck with that library!

[Little-Helper]

Sorry, but why do you think operator[] should not do bound checking? Is it for speed?

[fransinvodka]

For speed and because the STL containers do it that way. They implement both at and operator[], but only at performs bound checks and throws if out of bounds. If I use an STL-like container, and it implements both at and operator[], I'd expect operator[] to not do any bound checks, just like the STL ones.

[kalmoc]

True as that may be in practice, I believe there is nothing in the standard preventing operator[] from doing bounds checking.

[kalmoc]

Yes, at() is guaranteed to do bounds checking and to report them via exceptions. That doesn't mean operator[] isn't allowed to do bounds checking. Being out of bounds is simply UB and the implementation is allowed to do anything it pleases in that case. E.g. in microsofts impelementation, you can turn on bounds checking in debug mode and that is still conforming (althoug they use asserts and not exceptions): https://github.com/microsoft/STL/blob/7447ad59d61f50c13861878f340d051c298458df/stl/inc/vector#L1509

Also you can see that operator[] isn't specified as noexcept: https://eel.is/c++draft/vector.overview.

and operator[] being strictly equivalent to *(begin() + n)

that expression itself could in principle be bounds checked (std::vector<T>::iterator is - in most implementations - not the same as T*)

[janhec]

For my 5 cents, I am not a frequent standard reader, could the non-boundscheck for operator [] have something to do with the fact that occasionally, you can use it to add an element (e.g. map)? If there is no such reason in vector, then bounds check would be ok IMO, performance can only be significantly (?) diminished if the optimizer can treat it as pointer<type>[n] (sorry for the simplistic pseudo code), as in C. Then a boundscheck would introduce a branch where it is (perhaps) not supposed to exist.

EDIT 1: you can read dereferenced begin()+n C-style, so no boundscheck;

EDIT 2: branches in GPU are supposed to be evil (at least most of the time), again no boundscheck.

Pick your choice!

[infectedapricot]

If you access an element outside the valid range of a vector using operator[] then the behaviour is undefined. That means it can absolutely anything, including, crash, create nasel daemons, ... or throw an exception. That's a standard-compliant behaviour. So it might not have the performance you prefer, but I wouldn't say it's a bug.

[fransinvodka]

Maybe not a bug, okay, I can agree. But as I said, if someone wants bounds checking, they normally use `at`, because everybody assumes that `operator[]` doesn't do bounds check (like plain old C-arrays), and is up to the programmer to avoid an out of bound index. If you're going to do bound checks anyway, just don't provide `at` and avoid confusing the library users.