Modern C++ Won't Save Us

A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein&#x27;s monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments.<p>I&#x27;ve noticed that more and more people like me have and use large alternative history &quot;standard libraries&quot; that add functionality, reimagine the design, and in some cases reimplement core components based on a modern C++ cleanroom. I&#x27;ve noticed that use of the standard library in code bases is shrinking as result. You can do a lot more with the <i>language</i> if you have a standard library that isn&#x27;t shackled by its very long history.

This has been discussed extensively in the C++ community. I think if you need a very safe code, you shouldn&#x27;t use the string_view or span without thinking about the potential consequences. These are added to the language to prevent memory allocation and data copy for performance critical software.<p>Herb Sutter has concrete proposals to address this issue and Clang already supports them: <a href="https:&#x2F;&#x2F;www.infoworld.com&#x2F;article&#x2F;3307522&#x2F;revised-proposal-could-solve-longstanding-c-bugs.html" rel="nofollow">https:&#x2F;&#x2F;www.infoworld.com&#x2F;article&#x2F;3307522&#x2F;revised-proposal-c...</a>

It is true, C++ has several warts some of them caused by the copy-paste compatibility with C.<p>Which is both a blessing and a curse. A blessing as it allowed us Pascal&#x2F;Ada&#x2F;Modula refugees never to deal with what was already outdated, unsafe language by the early 90&#x27;s.<p>But also makes it relatively hard to write safe code when we cannot prevent team members, or third party libraries, to use Cisms on their code.<p>Regarding the alternatives, Swift is definitly not an option outside Apple platforms. And even there, Apple still focus on C++ for IO Kit, Metal and LLVM based tooling.<p>Rust, yes. Some day it might be, specially now with Google, Microsoft, Amazon, Dropbox,... adopting it across their stacks.<p>However for many of us it still doesn&#x27;t cover the use cases we use C++ for, so it is not like I will impose myself, the team and customers, a productivity pain, take the double amount of time that it takes to write a COM component or native bindings in C++ for .NET consumption just to feel good.<p>When we get Visual Rust, with mixed mode debugging, Blend integration and a COM&#x2F;UWP language projection for Rust, then yeah.

The C++ people are trying to refit ownership to the language without adding a borrow checker. This is painful. They&#x27;ve made it possible to write code that expresses ownership, but they can&#x27;t catch all the places where the abstraction leaks.<p>string_view is really a non-mutable borrow. But the compiler does not know this.

From the article:<p>&gt; Dereferencing a nullptr gives a segfault (which is not a security issue, except in older kernels).<p>I know a lot of people make that assumption, and compilers used to work that way pretty reliably, but I&#x27;m pretty confident it&#x27;s not true. With undefined behavior, anything is possible.

I really don&#x27;t get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn&#x27;t without it&#x27;s warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you&#x27;ll end up writing your CUDA code in C++ anyways. I guess you could go the route of writing bindings, but that is not without additional effort. Not that it won&#x27;t happen for Rust, but C++ also has tooling suited for enterprise use that are largely unmatched in other languages (Visual Studio, Qt, etc). Sandboxing, static analysis, and fuzzing tools are also mostly built for C&#x2F;C++ codebases. It&#x27;s also an ISO standard language which makes it both a language full of warts due to decision by committee, but also a candidate for a stable, long-lasting language that will outlive many of us. (Try finding an ISO Standard Language you don&#x27;t hate).<p>Either way, C++ is certainly not for every project, but the articles scattered around the web claiming it should be superseded by Rust are plentiful. These opinion pieces make no attempt to credit C++ for when it <i>does</i> make sense to use. Despite it&#x27;s quirks, it is still the most optimal way to program HPC applications or cross platform GUIs that are not Electron based. The security tools around it and the fact that it&#x27;s an ISO standard language make it a solid choice for many enterprises.

What do you need saving from - Ada has existed for nearly 30 years now ; )

Can someone at least make a linter that ensures you only use a &quot;safe&quot; subset of C++?

For systems programming languages, safe by default with scoped unsafe code is a Pareto improvement on unsafe everywhere.

Question - How does one write microcontroller code (or other memory-mapped I&#x2F;O code) using a memory-safe language?

Many of the problems he talks about come from the lunacy of the C++ compiler making all sorts of temporaries and calling hidden type conversion functions, making all sorts of assumptions that it should never ever ever make without being told by the programmer. That is why C will always be a better language than c++ on a fundamental level. In this area stroustrup took C in a bad direction.

The string_view issue has popped up even in relatively safe languages. Java&#x27;s String class used to do something similar, where substring returned a String that referenced the original String object&#x27;s internal array to avoid a copy. They gave up on it because too many people accidentally held a references to large strings and leaked memory that way.

There is no call in the article for a deeper C++ code analysis by the compiler. Deeper analysis will be the future of C++ - the article fails to foresee this.

<i>&gt; Nonetheless, the question simply must be how we can accomplish it, rather than if we should try. Even with the most modern C++ idioms available, the evidence is clear that, at scale, it&#x27;s simply not possible to hold C++ right.</i><p>So, how then? That&#x27;s the main question indeed :)

Today&#x27;s C++ will be considered a cobbled together relic in a few C++ standards time periods!

The stringview example is surprising and certainly something I could have fallen for.<p>I feel like the lambda example is pretty contrived. If I was returning a lambda that was capturing values by reference, I would already be pretty wary of UB.

&gt; Dereferencing a nullopt however, gives you an uninitialized value as a pointer, which can be a serious security issue.<p>Is this really true? Surely it just gives you an uninitialised `int` (or whatever is in the `optional`)?

Rust and Swift have different definitions of memory safety, don&#x27;t they?

Any HN post mentioning C++ will inevitably be invaded by the Rust Evangelism Strikeforce.

Without any data to back this up, my guess is that there is no good reason to pick C++ for a new project except when the developer is already fluent in C++.<p>Assume we have this abstract developer that has a good knowledge in programming theory but has no experience in programming languages.<p>The developer starts a new project, but in what language?<p>web: Don&#x27;t see any reason for this. Exist lots of great alternatives. This is not really one of C++ strengths so is not that strange.<p>desktop-GUI: Probably one of the biggest strengths of C++ is the Qt framework, it is solid choice. I can see this a possible choice. However with electron dominating &amp; PWA:s becoming a more viable option it is probably much higher chance that a HTML&#x2F;JS environment is picked instead, especially how it already dominates the web. And by using TypeScript you can do it an solid language.<p>mobile apps: Most apps are written in some web technology or directly with Swift or Java. Qt has some support for this, but not sure how widely used. My experience with NDK was not pleasant. I can&#x27;t really see this as a viable option.<p>embedded: I don&#x27;t do embedded, but my understanding is that plain C is much more common here &amp; if faster development is needed you integrate something like Lua. Maybe?<p>memory safe: use rust I guess.<p>compiled binary: Use golang, no complicated buildstep.<p>Parallellism: Better to use a language designed for this like erlang.<p>Game development: For the majority of games today a scripting language like JavaScript or Lua is good enough. HTML&#x2F;JS has some really good frameworks for game development today.<p>3D game development: Probably a good fit to use C++, but I think that C# with Unity is a much better choice. Great framework, good community, however C++ is not bad choice for this. Possible.<p>Commandline tool: If the developer is building the next grep, C++ could fit that, but most commandline tools does not have that performance requirement, Probably do some HTTP, JSON decoding, DB access. Bash is good enough or any other dynamic language.<p>Scientific: my understanding is that today this is mostly python or matlab. Maybe?<p>System development (drivers etc): I know too little about this to make a good assessment, to be fair I put this as a possible choice.<p>And if the developer do decides to use C++ for a new project, the initial cost is quite high to just understand the basics, even if he&#x2F;she uses the latest C++ version. Copy constructors, lvalue &amp; rvalue (xvalue, glvalue, prvalue...), move semantics, const refs, rvo, smart pointers, auto etc<p>Any good arguments to pick C++ for a new project?

<i>&quot;Don&#x27;t be clever&quot;</i>. Yes. In the CppCon 2017 opening keynote: The Learning and Teaching Modern C++. The accompagnying slide says &quot;Don&#x27;t be (too) clever&quot; but I can&#x27;t promounce parentheses :-). My point was to discourage overly clever code because &quot;clever code&quot; is hard to write, easy to get wrong, harder to maintain, and often no faster than simpler alternatives because it can be hard to optimize. - Bjarne Stroustrup

Can virtualisation solve this ? Is it possible to have a virtualised environment like Qubes but for programs ?

There was an article recently about a behavior which in a recent version of C++ was made from defined behavior into undefined behavior, because making it undefined allowed for better compiler optimizations.<p>I always thought that undefined behaviors were historical accidents. But apparently sometime people just say &quot;hey, lets add a few more undefined behaviors&quot;<p>This is the insanity of C++