I used to have all kinds of problems with array overflows. I didn't make them very often, but when I did, they took a long time to track down. They've been gone for 20 years now.
Note that it would be easy to add it to C/C++:
https://www.digitalmars.com/articles/C-biggest-mistake.html
It would be the most useful and cost-effective enhancement ever.
I wanted to ask: did you ever consider what was missing from Dlang to achieve widespread adoption? Clearly it was not features, so I'm wondering what that would be from your pespective.
For example, Borland at one point decided to include the source code to some of its runtime library for free. At a compiler roundup in the magazine, this was hailed as a great advance forward by the reviewer. Meanwhile, Datalight C was also in the roundup, and had always included 100% of the runtime library source code. No mention was made of this.
They care now (well they pretend at least) because Rust is going to take significant market share in domains where C++ is still king.
And then evolution will take care of which programming ecosystem are less expensive to result in lawsuits, or invalidation of insurance policies.
No, it's not the same. I never enable optimisations by manually passing in flags to the compiler. It's always a `cmake -DCMAKE_BUILD_TYPE=...`. There is no such easily accessible equivalent for bounds checking.
Maybe I'm not getting what you mean.
You are saying you already run
cmake ...
CXXFLAGS="-Dblah" cmake -U CMAKE_CXX_FLAGS ...
In any case, any beef you have is clearly with CMake here. You'd have the same issue(s) with any other flag, for any language, if you use CMake.
Lol then you don't use your compiler/toolchain correctly. How is that anyone's problem but yours?
This turned out to be the right move.
All I was doing here was saying was that the fix for your "C's biggest mistake" (your T arr[..] proposal) is already in C++ and you can get it today: it's called std::span, and it was explicitly designed to let you get bounds-checking, with just a different syntax. It needs a compiler flag, and so do optimizations. You already pass one, so pass the other too, and get what you wanted.
That was all I was saying. But this being HN, everyone insisted on derailing this into an argument about whether safe-by-default is better than fast-by-default, when that had nothing to do with my point, and when I was certainly not trying to argue one is better than the other.
If you propose something with blatantly obvious flaws here, you'll usually get called out.
You suggested that people use an interface without bounds checking and jump through a hoop to enable bounds checking with it. Other people disagreed that this is a solution. You kept digging deeper after that while ignoring their responses, but that's on you.
The problem you don't seem to understand is that, with this being HN, if I'd told people to use gsl::span, then I would have had a similar barrage of people "calling me out" for it having the "obvious flaws" of (1) destroying performance for users who don't want it, and/or (2) being nonstandard and in no way equivalent to the dlang.org proposal, this is why C++ sucks, blah blah. I might as well have just told them to write their own configurable wrappers at that point.
So I proposed std::span because it was literally the standard solution that was explicitly designed to let people get bounds checking without those problems... so that they can have their cake and eat it however they want, without an immediate performance loss. I frankly thought that was obvious, but this being HN, I was greeted with people "calling me out". It's like it's impossible to tell people something useful here without writing a comprehensive dissertation on the general topic. Makes me regret trying to help people.
It is not in the standard, it isn't neither portable, nor guaranteed to exist.
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.
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.
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.
[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p01...
It’s not hard to grok.
Nobody was ever saying that unsafe-by-default is somehow better. That just wasn't the question being asked.
Can your position not be summed up as “unsafe by default doesn’t matter, because changing the default is easy”?
If so, there’s an obvious flaw in that thinking.
No.
>> Nobody was ever saying that unsafe-by-default is somehow better.