Uh no, vec[i] may be unprotected in release mode but all three major standard library implementations, MS STL, libc++ and libstdc++ have bound checking in debug mode (along with many other sanity assertions, such as correct sorting predicates, etc) ; this way you get the (horrendous) bound-checked cost when developing and can ensure decent performance in release.
I do as far as is possible all of my development under my stdlib's debug mode with -fsanitize=address and -fsanitize=undefined. If it's slow like this on my 2018 workstation, it'll be slow in release mode on my users's 2011 dual core laptops and on raspberry pis.
but if you need a bit more speed you can still build with
-O2 -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1 # for libstdc++
-O2 -D_LIBCPP_DEBUG=1 # for libc++
/O2 /D_ITERATOR_DEBUG_LEVEL=1 # for msvc
this way you get compiler optimizations but the assertions are still there
Well, there is always a option to enable bounds checking in operator[](), all major compilers provide defines or compiler switches for that, and I would advise anyone that cannot prove otherwise via a profiler to do just that.
Not bragging at all.. it was just introspection on how different my code looks now… maybe I should find some older code that is fraught was dangerous constructs. In fact, early versions of this were segfaulting for the very reasons you mention.
Your comments come across as pretty mean-spirited. Let me rewrite one line for you. You wrote:
> Someday one of your coworkers is going to break it and this code will be trashing the heap. Mysterious memory corruption failures are your destiny.
You could have written something like, "It's possible this code will break in the future and you won't even realize the cause, because it will appear as a mysterious memory corruption failure."
See how I left out a word like "destiny" and took out the whole bit about coworkers? Yeah, much nicer and less personalized.
The point of the post by my fellow HN person was to give you feedback on your communication style.
You obviously have interesting things to say and opinion to share with a fair amount of passion, but the tone detracts from the message, which I find a pity.
It’s not about people being delicate, its about what you value more: saying whatever you feel like saying, or actually getting your point across.
The more inflammatory your tone, the less likely it is that you’ll change anyone’s mind, because they’ll be more likely to dismiss outright whatever you’re saying.
This quote doesn’t exactly make you look like the badass you think you are.. and all over C++ array access. Does that sound like a topic that warrants escalation to confrontational language to you?
The most dangerous thing I do is index a `std::vector` for which I can add range checking -- which I only do when debugging -- I am not willing to pay for that at release time. I am not performing any address math that can not be statically or else dynamically checked. No explicit memory allocation anywhere -- C++ does all the memory management for me. This is not true of older code I have written.
To me the code looks like very reasonable c++, and quite modern. I suspect the comment about memory safety may have been related to leaning heavily on things like iota, copy, partial_sort, lower_bound, etc as opposed to doing those things “by hand”.
However, your code is full of vector accesses without bounds checking: vec[i] instead of vec.at(i).
That's just as "unsafe" as C, so I recommend not bragging about how far you've come.
Your code is full of what is essentially unprotected C-style
You've been writing C++ since the 1980's, but your code is full of raw pointer math, and yet... "No worries about memory safety"?I have a feeling you'll be reaching for Valgrind or address sanitizer someday soon, just like the C programmers.