[constantcrying]

I imagine the reason bounds check are cheap is because of the branch predictor. If you always predict the in bounds path, the check is almost free.

You also do not really care about flushing the pipe on an out of bounds index, since very likely normal operations can not go on and you move over to handling/reporting the error, which likely has no need for significant throughput.

Also I would just like to note that safe arrays aren't a unique rust feature. Even writing your own in C++ is not hard.

[int_19h]

It's not hard, but when the idiomatically used containers aren't bounds-checked, most code out in the wild won't be, either. Worse yet if you are writing a library and have to interop with other code which will also use those idiomatic types.

These days, C++ really should be compiled with bounds-checked indexing and iterators by default. Unfortunately, this is still not a scenario that is well-supported by tooling.

[pjmlp]

On VC++ it is quite easy to do so,

https://learn.microsoft.com/en-us/cpp/standard-library/check...

The hard part is changing the mentality from whoever sits at the keyboard.

[int_19h]

FWIW it looks like they're planning to kill it off for release builds: https://github.com/microsoft/STL/issues/277

In my experience with them, the performance hit is far more substantial that a few percent, except in situations where the compiler can elide the checks altogether. For example, simply iterating over std::vector with _ITERATOR_DEBUG_LEVEL=1 is twice as slow if you work with iterators explicitly instead of writing it as a range-for.

And I'm not sure if it can be substantially better, given that C++ as designed simply needs to do more checks to ensure validity - to catch cases like comparing iterators belonging to different containers, or iterators getting invalidated when containers get resized or when the corresponding element is deleted outright. This all can't be done with simple ranges or slices, which is why VC checked iterators maintain a reference to the parent container.

[pjmlp]

Oh, so much for VC++ folks being security conscious.

The performance hit from bounds checking was never an issue for most applications I have done in C++.

Why C++? WinDev likes it a lot, alongside COM, and not everything is exposed to .NET.

[int_19h]

Array bounds checking is plenty fast, it's the iterators specifically that are the problem. Unless your code is heavy on those, you wouldn't notice.

(OTOH for cases where you would notice, given the perf penalty, you might as well just write it in C# then.)

[jackmott42]

Yep, unless your code is wrong, the bounds check will always be predictable. Which makes it free in a sense. But sometimes it will block other optimizations, and it takes up space in the caches.

[pantalaimon]

That would be bad on Embedded where MCUs usually don’t do any branch prediction.

[dathinab]

> If you always predict the in bounds path, the check is almost free.

Note that you often only branch in the "bad" case, which means even on systems without branch prediction it tends to be not very expensive, and compilers can also eliminate a lot of bounds checks.

[pjmlp]

Yeah, but it only works in practice if you are only one coding the application, or there are strict rules in place to not do C style arrays.