-
Notifications
You must be signed in to change notification settings - Fork 738
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
operator[] checks whether given index is valid. #889
Comments
Usually it is the at() that does the bound checking. Does at() do bounds
checking?
…On Mon, 25 May 2020, 09:57 Andreas Forster, ***@***.***> wrote:
I was interested in the reasoning for this bound check here and why that
it is not guarded by #ifdef NDEBUG:
https://github.com/microsoft/GSL/blob/master/include/gsl/span#L613
This can be quite a big performance hit. Are the maintainers interested in
a pull request that changes the Expects/Ensures macros when NDEBUG is
defined?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#889>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGL3HGQB6GI5CQJVZ7LUZLRTIXJJANCNFSM4NJLDXZA>
.
|
Hi, |
The intended behavior of gsl::span is to guarantee bounds safety in all access operations, which is why we intentionally do not wrap these checks in NDEBUG. |
Ok, I guess if this is by design I will close the issue. |
well, C++ standards says that it's a precondition that the index is valid https://eel.is/c++draft/span.elem#1 |
Maintainer's call: We actually are following the span design on purpose, however the only difference is the bounds checking. The intent is to be able to simply using a different namespace and it will still work. |
I was interested in the reasoning for this bound check here and why that it is not guarded by
#ifdef NDEBUG
:https://github.com/microsoft/GSL/blob/master/include/gsl/span#L613
This can be quite a big performance hit. Are the maintainers interested in a pull request that changes the Expects/Ensures macros when NDEBUG is defined?
The text was updated successfully, but these errors were encountered: