Because turning on optimizations makes your code faster and turning on bounds checks makes your code slower. Hence, one gets used far more than the other.
> Because turning on optimizations makes your code faster and turning on bounds checks makes your code slower. Hence, one gets used far more than the other.
The question was "is it so hard to pass a command line flag". You said "yes" when you clearly don't see any difficulty with actually passing the flag. Instead you're apparently answering a totally different question: "why do people lack the motivation to do this." Which had nothing to do with the point you replied to.
It's not like opt-out vs. opt-in somehow changes the performance characteristics. People who want maximum performance will turn it off. People who want safety will turn it on.
Is it so hard to shoot someone? It's just pressing the trigger. When you say it's hard to kill people you're really just answering a different question, one that is about the psychological or legal or moral cost of doing so. Maybe your overly literal interpretation is not the one people actually want.
> Is it so hard to shoot someone? It's just pressing the trigger. When you say it's hard to kill people you're really just answering a different question, one that is about the psychological or legal or moral cost of doing so. Maybe your overly literal interpretation is not the one people actually want.
You don't feel you're missing the point of the discussion?
The whole discussion started with: "if you want bounds checking in your own code". Notice the "if". That's the premise.... it by definition assumes you've already accepted the performance impact of getting the safety you want, and thus it's not a problem for you.
The only remaining question at this point is, how hard is it to get you that safety. Asking you "is it so much harder to pass -foo like the -bar you already pass" and expecting you to address the physical difficulty of adding a flag isn't taking an "overly literal" reading of the question, it's literally asking the most obvious and only remaining question.
If you want to go back to the premise and argue about the psychological hurdle of taking a performance loss, that's fine and all, but then you're completely changing the topic of the thread you replied to.
P.S. comparing passing an extra command-line flag to shooting someone is a rather insane comparison. Honestly, all this is really making me regret trying to share a tip to help people make their code safer.
You're regretting it because you keep telling people to use an interface that explicitly was designed to not provide bounds checking and claiming that this is the solution to make their code safer, while in reality you have to look up some nonportable flag to enable it for your STL if even offers the functionality at all. Maybe people would be a lot more reasonable if you didn't post intentional bait in the first place.
No, I'm regretting it because having to spend hours replying to comments that ignore the premise is a complete waste of my time.
> you keep telling people to use an interface that explicitly was designed to not provide bounds checking
As a matter of fact it was very intentionally and specifically designed to allow bounds-checking to be configured at build time: "As an example, in the current reference implementation, violating a range-check results by default in a call to terminate() but can also be configured via build-time mechanisms to continue execution (albeit with undefined behavior from that point on)." [1]
Calling that "explicitly designed not to provide bounds checking" is quite a deceptively misleading way to paint it. It's not an accident that you can enable bounds-checking, it's very much by design and intended that you do so. They just didn't happen to standardize the flag name, just like they never standardized the optimization flag names.
> and claiming that this is the solution to make their code safer, while in reality you have to look up some nonportable flag to enable it for your STL if even offers the functionality at all.
Like I said, this is literally the same as optimization flags. Everybody passes them and nobody bashes C++ for it. You're making a big deal out of something incredibly tiny just to win an internet argument on the wrong thread.
You're the one misunderstanding here. The reference implementation that they provided (which I actually believe is gsl::span) allows configuration. The design for the standard, as you have mentioned elsewhere in this discussion, does not provide bounds checking. I am making a big deal out of this because it is a problem that affects real codebases, not something hypothetical that you can wave away with your idea of how things work. The fact is that people who care about security ship non-bounds-checked spans because this is not the default option.
