The "Core Guidelines" site hidden in the references is a gem.<p><a href="https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines" rel="nofollow">https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines</a>
> This static analyzer causes programmers to use 2 extra characters when using smart pointers, -> vs (*)., since the overloaded -> operator returns a pointer.<p>This renders it completely impractical -- sorry. You need to figure out a way to make it work, otherwise this is, errrm, useless.<p>And what is 'this' static analyzer anyway. I thought this is about a language extension introducing possible general static analyzers. Is this a concrete one now? Or why do you already know that it cannot handle '->'? Did I miss something? What is this?
Generalized rules for how to use C++ in all situations are aspirational and unlikely to be adopted widely. More practically, the large projects that rely on C++ should just have their own rule on what elements / styles are used in that particular project, and then use a linter to enforce those specific rules, and have good documentation that explains the rules.
I have a couple of gripes with these guidelines, not because I love writing unsafe programs, but because this way of writing C++ conflicts with the reality of how C++ is implemented.<p>1. shared_ptr is <i>very</i> slow. It makes it safe to share data, but at the expense of many tiny allocations for each object type. C++'s memory manager isn't geared towards that kind of abuse, this is something that can really only be performant in a garbage-collected language where allocation is an atomic pointer increment and deallocation happens "later". Pushing people towards using this abstraction is wrong most of the time, it is often much better to use arena-style allocations for most cases in C++. I've seen libraries written in modern C++ where malloc and free account for 80% of the runtime. I don't see a way to fix this without radically altering the memory manager.<p>2. The impact on code compiled in debug mode is often unacceptable. I expect programs compiled with minimal to no optimisations to be slower, but layering all these abstractions usually produces a lot of runtime junk that gets in the way. For example, std::for_each can often be optimised to a regular for loop, which can then be vectorised, but in debug mode it is compiled to a function call which in turn calls the passed in lambda for each element and operator++ on the iterator. The difference in speed between the two is several orders of magnitude and makes this abstraction unacceptable for hot loops. This is a more minor gripe that can probably be solved by marking some functions as "function-like macros" similar in intent to LISP's macros, so the compiler knows they can be always inlined and optimised. GCC's -Og flag also helps a lot here. Still, the world isn't just GCC and the standard should probably bequeath more library functions with special status, like how memcpy &al can be always optimised to inlined machine code instead of a function call.<p>You'll notice both of those concern speed. If the loss of performance from said abstractions is not a deal-breaker for you, then you probably shouldn't be writing C++. D, C#, go, Java, maybe even JavaScript, Python or Lua would be a better choice for your project. The reason to use C++ for a new project is because you want to build really complex programs made up of operations that closely match the semantics of the machine on which they run, for the purpose of going <i>very fast</i>. Or you're stuck using C++ because you have to interface with C++.
So, the context for these "... is the next C++" talks, blog posts and papers is largely Chandler Carruth's CppNorth talk: <a href="https://www.youtube.com/watch?v=omrY53kbVoA" rel="nofollow">https://www.youtube.com/watch?v=omrY53kbVoA</a> "C++: What comes next?" which is also the "coming out" for the Carbon language.
I might get totally misunderstood ^^ but I will try to post an opinion from gamedev side.<p>I have spent lots of time thinking on all proposals that came up this year. And only one idea felt seriously better. No not the 'secure rust'. The idea behind Circle compiler described by author in one of podcasts I think. That compile time language should stop being ugly magic and should become normal full fledged programming language that can do everything.<p>Recently I have investigated some failures in builds that were happening only on one platform only in one branch only when specific change was applied. And I came to conclusion that gamedev does not have people who understand what C++ does at compile time. And to fix it we don't need more more magic in C++. So no, next C++ will not be C++ for us if we will have any other sane alternative. Most likely we are stuck with old C++ until new platforms are out.
I know this is off topic, but right out of the gate, this really irks me...<p>Re >> "<i>Software companies have a problem. There’s not enough candidates that can code C++. </i>"<p>Should be written "<i>There're</i> not enough candidates <i>who</i> can code C++."
More static analyzers is the way to go<p>Similarly, D also is pushing for more static analysis to enforce safeties<p>I feel like D already is the next C++, it feels like C++ catching up on D, they went with the same syntax as D for modules, it's quite telling
I wonder how much C++ is being learned by new generations of programmers. I suspect Rust is taking over there but that is a completely baseless assumption on my part.
The successor to C is Go.<p>Go inherits from Oberon through Robert Griesemer, and from C through Ken Thompson (father of Unix) and Rob Pike (Bell Labs).<p>I don't bother with C anymore, except in small parts of code where every cycle counts. Just about anything you write in C can be mechanically translated to Go.<p>C++ shows us what NOT to do. I've used C++ for most of my professional programming career and it's simply an impediment. Huge waste of time and energy.