Bjarne Stroustrup on C++ large compilation times... "I really like Scala because makes C++ look fast" :-)) - https://youtu.be/2BuJjaGuInI?t=5070

I think in a ideal world it would be possible, but people won't stop writing C in C++, and that makes static analysis quite hard.

Visual C++ support for it is pretty much WIP, full of false positives.

Would someone mind giving a description of "writing C in C++"?

It seems a bit off to me to claim it's a superset of C while banning the subset of C.

Like it or not, C++ does have things like raw pointers, null terminated arrays, setjmp/longjmp, and macros. That's part of being a superset of C. Using them in C++ is still C++ if it's compiled by a C++ compiler.

It may not be idiomatic, but I'd love to see the C++ community come up with a single definition for idiomatic C++. And to preempt the answer of "idiomatic C++ is Modern C++" -- How about things like exceptions, rtti, and iostream?

> Would someone mind giving a description of "writing C in C++"?

For starters, write non-idiomatic code which employs (exclusively or not) a subset of features.

Imagine writing Python and only using free functions, while vehemently refusing to use stuff like classes or list comprehension or exceptions or anything at all. Similar to "writing C in C++", this would be "writing shell scripts in Python".

> Like it or not, C++ does have things like raw pointers, null terminated arrays, setjmp/longjmp, and macros. That's part of being a superset of C. Using them in C++ is still C++ if it's compiled by a C++ compiler.

You're missing the whole point.

"Writing C in C++" is synonymous to "not using new C++ features that are safer and faster and better than the old C features".

It's completely irrelevant if the compiler supports raw pointers or preprocessor macros. The whole point is that, say, intentionally using raw pointers when you have smart pointers is hardly justifiable, and you're not doing yourself any favor.

I can understand if people want to avoid using classes. But list/dict/set comprehensions make building complex data structures easier and more performant.

Usually, if one avoids OOP features of Python, that means he/she likes to use more functional features. And vice-versa.

I imagine it's the same with C vs C++. People use malloc/free, classic for loops and structs+functions only because that style fits their mindset better.

Bjarne even gave an example at the talk with span versus pointer and length as argument.

Writing C in C++ means exactly that, writing C++ code in the subset that is also valid C, while ignoring everything else that the language offers regarding type safety, including basic stuff like RAII, or templates instead of macros.

Technically it is C++ code, in practice can be compiled with a C compiler as well.

> It seems a bit off to me to claim it's a superset of C while banning the subset of C.

C++ is not a superset of C.

Unfortunately, I'm very well aware

Rust's advantage is that it performs static analysis at compile time. The only reason to believe that identical static analysis can not be done without the magic of Rust is religious fervour.

Rusts advantage is that is has made language level design tradeoffs to achieve semantics that allow for this kind of static analysis.

And they only just barely managed to get something usable in the beginning. Rust ergonomics have improved a lot since 1.0.

The criticism here is that C(++) advocates often claim the language is fine, and static analysis is enough to fix the problems.

Rust is hopefully just a stepping stone to something better, but the assumption that no new language semantics are needed is denial.

All static analysis is performed without executing the program. That's the definition. Whether an analyzer is runs before codegen or after is not an incredibly meaningful distinction since both can be integrated for developer environments in precisely the same way.

The magic of rust is that it forces all code to go through this static analysis to even compile. You can't avoid it. Even `unsafe` goes through it but with some additional freedom. The language is designed around static analysis, for example there's syntax for lifetimes and mutable/immutable references with their lifetime.

I see no evidence that C++ (or any language) can provide the same level of confidence, without having the same sort of support in the language itself. An analysable fragment of C++ might be a thing; rust level guarantees for the whole language is very unlikely.

That the language does not force you to use static analysis does not entail that it is not possible.

Where I work, most C code can not be checked in to source control until the CI bot is satisfied with the static analysis run. That's necessary because of C's separate compilation model: static anaylsis requires whole-program analysis to track aliasing.

Rust is a single tool that does (or may do, when opted-in) static analysis. It's not the first, not the only, and probably not the best. Other development environments use separate tools for separate operations. Engineering has always had its lumpers and dividers. Rust and Windows is for lumpers, C and Unix is for dividers.

The proposed c++ static lifetime analysis does indeed require language kevel annotations.

IIRC the Chromium devs have investigated and thought a lot about this and the TL;DR is: They don't believe it can be done.

(I'd be inclined to take their word on it over Bjarne's.)

I'm not sure this is where I originally read their conclusions, but lots of info about this, regardless: https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76D...

> IIRC the Chromium devs (...)

Chromium is hardly a compiler or tooling project. Even if their devs aren't hacks, appeals to authority based on their perceived expertise hardly make any sense.

Having said that, there is no better litmus test than showing something working. If Dr Stroudtrup strongly believes in C++'s ability to provide Rust-like memory safety guarantees, there's no better person than him to prove him right (or wrong). If he does not have a proof of concept in the works, he's not in a good position to substantiate his claim.

FWIW, Chromium contains a Javascript compiler and developer tooling.

I'm not saying it's proof or anything. It is evidence that it's likely to be very hard (if not impossible).

> It is evidence that it's likely to be very hard

I don't agree. Chromium is an end-user of compilers and tooling that originated in forking a third-party desktop app. Developing C++ compilers and static code analyzers is way way outside of their wheelhouse. What they can and cannot do outside of their wheelhouse is hardly relevant or representative.

I think you under estimate just what level expertise and pull modern web engine requires. Google funded a ton of the work to support clang building code for Windows explicitly so they could standardize on clang for Chromium on all platforms. In turn they used the fact that they use a single toolchain across all platforms to add support for things like control flow integrity, which involved low level ABI and runtime changes to to the compiler and libc++. That requires tight cooperation between the Chromium and the compiler teams, and is definitely beyond a typical "end-user of compilers and tooling."

Admittedly my claims about Chromium are based on my observations as an outsider, but as someone who works on tooling (linkers) at a different large company that also has a web engine written in C++ I can tell you it is consistent with what I have seen up close... web engines (and particular JavaScript JITs) tend to push C++ tooling hard and often inspire major investment by the teams working on C++ specifically to support them.

In fact, over the years I have seen a number of people (including C++ committee members) who transitioned back and forth between the C++ compiler teams and the JavaScript JIT teams because they sometimes work very closely together, so in my experience the level C++ expertise on lot of the teams developing web engines tends to exceed anything but the actual C++ tooling teams supporting them, and developing C++ tooling is most certainly in their wheelhouse.

We didn't go to the moon because it was easy, we went to the moon because it was hard.

It can probably be done if you restrict some of the language features. e.g. reinterpret_cast, unprovable static_casts uninitialized pointers, etc etc.

Statically provable memory safety is probably possible in some sorts of code, like business process logic where performance isn't critical, and you can use std:: containers and copy everything.

A browser is a much more demanding environment, involving code generation, multithreading, caching, and low-overhead interfaces to complex data structures. Memory safety is extremely hard in that case.

So both could be true.

For correctness’s sake let’s add that the problem domain of Chromium doesn’t allow for only-safe Rust. Recursive life cycles are not enough here, and for performance reasons (A)RC is neither.