7 ms·

It's also interesting that Bjarne thinks that we can get full Rust-like memory safety through static analyzers for C++: https://youtu.be/2BuJjaGuInI?t=5000 http

It's also interesting that Bjarne thinks that we can get full Rust-like memory safety through static analyzers for C++: https://youtu.be/2BuJjaGuInI?t=5000 https://youtu.be/2BuJjaGuInI?t=5000 But so far I haven't seen any convincing evidence that would prove (or give a high degree of confidence) that it can be done. It this just wishful thinking on Bjarne's part, or is there somewhere I could read on how he thinks that could actually be done in practice?

pjmlp 4y ago
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.
- chrsig 4y ago
  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?
  - pjmlp 4y ago
    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.
  - arinlen 4y ago
    > 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.
    - wheelerof4te 4y ago
      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.
  - q-big 4y ago
    > 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.
    - chrsig 4y ago
      Unfortunately, I'm very well aware
Quekid5 4y ago
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-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76D...
- arinlen 4y ago
  > 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.
  - Quekid5 4y ago
    I'm not saying it's proof or anything. It is evidence that it's likely to be very hard (if not impossible).
    - arinlen 4y ago
      > 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.
      - lgg 4y ago
        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.
bregma 4y ago
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.
- c-cube 4y ago
  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.
  - gpderetta 4y ago
    The proposed c++ static lifetime analysis does indeed require language kevel annotations.
  - bregma 4y ago
    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.
- UncleMeat 4y ago
  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.
belter 4y ago
Bjarne Stroustrup on C++ large compilation times... "I really like Scala because makes C++ look fast" :-)) - https://youtu.be/2BuJjaGuInI?t=5070 https://youtu.be/2BuJjaGuInI?t=5070

pjmlp 4y ago

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.

chrsig 4y ago
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?
- pjmlp 4y ago
  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.
- arinlen 4y ago
  > 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.
  - wheelerof4te 4y ago
    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.
- q-big 4y ago
  > 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.
  - chrsig 4y ago
    Unfortunately, I'm very well aware

Quekid5 4y ago

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-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76D...

arinlen 4y ago
> 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.
- Quekid5 4y ago
  I'm not saying it's proof or anything. It is evidence that it's likely to be very hard (if not impossible).
  - arinlen 4y ago
    > 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.
    - lgg 4y ago
      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.

bregma 4y ago

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.

c-cube 4y ago
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.
- gpderetta 4y ago
  The proposed c++ static lifetime analysis does indeed require language kevel annotations.
- bregma 4y ago
  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.
UncleMeat 4y ago
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.

belter 4y ago

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