3 ms·
But being footguns is a feature of C/C++, not a defect: they trade safety for performance by design. (Edit: Wrong trade-off in my opinion, just to make it clear
by debugnik 3y ago
But being footguns is a feature of C/C++, not a defect: they trade safety for performance by design. (Edit: Wrong trade-off in my opinion, just to make it clear.)
If you shop specifically for an unsafe tool, surprise, you get one. Should have picked better.
- dralley 3y ago1) The performance saved is negligible in many cases, for most footguns. Sometimes it's of no benefit, or slower than safe solutions to the same problem. 2) There's no reason to not just have the footgun be opt-in rather than it being the default approach, if performance does matter so much 3) Why is trading safety for performance the right decision in the first place? It's funny to compare the way software engineers talk about software with the way any other kind of engineer talks about their domain, or even how software engineers talk about other domains. How many threads have been had here over the past month about how unacceptable Boeing's "just turn off the de-icer" is to a hardware problem that could damage the engine, and other dodgy engineering decisions?
- debugnik 3y agoYou may have misread my comment, I'm on safe languages team. I'm complaining about the people that start projects in unsafe languages in exchange of a thin performance boost, and then blame the compiler/runtime maintainers for their own code being unsafe in exactly the ways the spec says it can be unsafe to give them such an extra boost. Personally, I think all remaining C and C++ projects should consider either rewriting in a safer language or adopting additional tools to prove (not just test) the lack of undefined behaviour. Trying to compromise is just giving us memory safety CVEs one after another.