Hacker News new | ask | show | jobs
by int_19h 1302 days ago
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.
1 comments
pjmlp 1301 days ago
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.

link
int_19h 1301 days ago
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.

link
pjmlp 1301 days ago
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.

link
int_19h 1300 days ago
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.)

link