11 ms·

Then you'd just repeat the Perl 5/Raku split. You'd have a "new" C++ that isn't actually C++ but it's called C++ with a different version number and people will

Then you'd just repeat the Perl 5/Raku split. You'd have a "new" C++ that isn't actually C++ but it's called C++ with a different version number and people will then bicker for a few years until they realize that the "new" C++ isn't actually C++ and that the "old" C++ just vehemently refuses to die, so they name it something else. The C++ standards committee can standardize a backwards-incompatible "new" C++ for all I care as long as they don't call it C++.

eternalny1 7y ago
I believe it's called Rust :)
- The_rationalist 7y ago
  Sadly rust lack some big features that c++ has like polymorphic inheritance, function overriding and function overloading.
  - SaxonRobber 7y ago
    I think that is for the best. I prefer less implicit behaviour in my code, even if it means my identifiers get longer.
    - NotCamelCase 7y ago
      Rust doesn't have function/operator overloading yet or it won't have it at all? I am vastly for clarity and simplicity over vague, implicit stuff but doing e.g vector operations can get very unreadable very quickly without it.
      - pjmlp 7y ago
        Rust has operator overloading, https://doc.rust-lang.org/rust-by-example/trait/ops.html https://doc.rust-lang.org/rust-by-example/trait/ops.html
      - SaxonRobber 7y ago
        Vector operations are one of the few cases where I think operator overloading is sometimes a good idea.
    - adev_ 7y ago
      That's a design choice. Less implicit means safer but also more verbose and more cumbersome to write. Rust priorities safety over everything else, also over productivity too in some case. Absence of function overloading and automatic type conversion is a good example of that in Rust. Is it the right choice ? Only time and multi-million line codebase will tell us.
  - the_why_of_y 7y ago
    Rust has "function overloading: the good parts" in the form of traits, inspired by Haskell's typeclasses. Rust does not provide the facility to strategically obfuscate code at scale like C++-style function overloading does.
- Koshkin 7y ago
  “fn... fn...” - No, that doesn’t sound like C++, at all.
  - dtolnay 7y ago
    Fn is spelled differently than auto but it sounds more like C++ than you might think. // C++ auto f() -> int32_t { return 1; } // Rust fn f() -> i32 { return 1; }
  - Iwan-Zotow 7y ago
    #define fn auto
    - Koshkin 7y ago
      Not a good idea: fn i = 0;
- vaylian 7y ago
  Rust is definitely a contender in the space. But philosophy-wise I think Walter Bright's D comes much closer.
- zrm 7y ago
  > I believe it's called Rust :) Yes, but no. When people design a language which they know is going to be incompatible, they tend to go all the way with it. If we're breaking it anyway then might as well do a better standard library interface than the stuff designed in the 90s and all that sort of thing, right? And that's good to have for new projects. But there is a benefit in having something which makes the smallest possible compatibility-breaking change to fix the defect in the original. So you have a "new language" with a borrow checker, but the standard library functions all have the same names and the same purpose and time complexity as the C and C++ ones, which would allow people to run the existing code through a transpiler which for 80% of the lines can be translated directly to working code in the new language, and produces diagnostic errors for the other 20% that explain what needs to be changed. Which removes 80% of the work from transitioning an existing codebase to the new language. And then more people do that.
rumanator 7y ago
> The C++ standards committee can standardize a backwards-incompatible "new" C++ for all I care as long as they don't call it C++. This x2. It's only C++ if you can optionally refactor random lines of code in a project written in compliance with C++98 using new features and still get a valid program. Once you mess with the language in a way that your C++98 code is either not supported or requires rewrites or redesigns to comply with the new standard then quite obviously it is not C++ anymore. Semver matters.
- badsectoracula 7y ago
  Under semver, they could call it "C++ 2.0" and be fine since according to semver anything with a major version change is free to break backwards compatibility.
  - rumanator 7y ago
    The hypothetical C++2.0 would have less to do with C++ than C++ would have to do with C, and no one disputes they are entirely separate languages.
  - paulryanrogers 7y ago
    While technically true so much of C++'s success is due to backward compatibility that I think the language would be instantly crippled. Java is in a similar situation, which is probably why they market the minor version.
    - pjmlp 7y ago
      Java and C++ have done several breaking changes, although not as bad as Python 3.0. The minor version for Java has stopped being used by Java 9.
      - heelix 7y ago
        Oracle calls the 6 month releases a 'major' version.. .but many corporate shops only care about the LTS versions (mostly 8 or 11) which are getting 90 day 'minor' patches. Java 11.0.6 is current till mid April, in which case 11.0.7 should hit. Our shops won't cut over to something beyond Java 11 until Java 17 (LTS version) hits in a few years. Just happy that we were able to make the jump from 8 to 11.
Fronzie 7y ago
C++ is deprecating things over time (https://en.cppreference.com/w/cpp/compiler_support https://en.cppreference.com/w/cpp/compiler_support), for example some uses of the volatile keyword (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1152r4.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p115...). So there is a path, but it has to take an upgrade-path into account for big legacy projects. In practice, moving to a new compiler can be a big project for companies with larger code bases. Sensible deprecation of features could (and in practice) is part of that. Even though the standard is quite careful, in practice big C++ projects sometimes rely on non-conforming behavior of the specific compiler version they use. An example is the MSVC template support which allowed constructs that the standard didn't.
- rumanator 7y ago
  > So there is a path, Your example is a really poor one. The volatile keyword was only used to provide hints to the compiler on whether or not it could apply some optimizations. Omiting a volatile keyword is perfectly backward compatible, as is compiling code without support for volstile. Thus the only practical consequence of adding/removing random volatile keywords from your source code was how your build could (and not should) be optimized. That's a far cry from, say, remove malloc().
  - roca 7y ago
    Ignoring "volatile" would actually break a lot of code, because it's typically used where common optimizations must not be performed.
    - ncmncm 7y ago
      Formally ignoring or forbidding volatile where it presently doesn't mean anything (despite fervent wishing) wouldn't break anything. Compilers would of course continue supporting whatever they do, but would be allowed to warn about dodgy uses. On MSVC, volatile has traditionally meant something akin to atomic. It still will, regardless of what the Standard says and other compilers do.
coribuci 7y ago
> Then you'd just repeat the Perl 5/Raku split. You'd have a "new" C++ that isn't actually C++ but it's called C++ with a different version number and people will then bicker for a few years until they realize that the "new" C++ isn't actually C++ and that the "old" C++ just vehemently refuses to die, so they name it something else. Well, just FYI the "new" C++ is not the "old" C++ anymore. Languages "evolve". Try to compile an old program on the new compiler. The same is valid for other languages (C, fortran, perl). > The C++ standards committee can standardize a backwards-incompatible "new" C++ for all I care as long as they don't call it C++. They already do this. For C for example you have C89, C93, etc.
- theamk 7y ago
  Huh? Old programs on new compiler work with very minor changes and often with no changes at all. You might have to tweak some compiler flags, but this is per file. Your project can easily mix up C++ versions. Same for C - that old library in C89? Still usable in modern projects.
  - pjmlp 7y ago
    Try to compile a library that uses gets() or K&R syntax in a C17 compiler.
    - AlexeyBrin 7y ago
      GCC 10 has no problem building C code that uses gets(), even with the -std=c17 compilation flag. You get a warning at runtime, but that's it.
      - pjmlp 7y ago
        GCC is one specific C compiler, it does not represent all of them.
        theamk 7y ago
        Just checked on gotbolt.com - clangg, icc, msvc all compile gets just fine. They also work with k&r style definitions as well. I am sure there are broken C compilers out there which don’t implement entire language. Heck, I use one sometimes. But I don’t think this proves your point at all. You need better examples.
m463 7y ago
python 2 vs 3 is a mess too.
- nnq 7y ago
  ?! Maybe was. A long transition... but it mostly happened already. Nowadays I'm mildly annoyed if a project is on one of those "ancient" 3 but ≤3.6 Python versions and I can't use the nice features in 3.7+...
  - klyrs 7y ago
    I keep encountering backwards incompatibility between various flavors of Py3. It's a mess and if you have a large codebase, staying on top of the latest version is a nightmare. Or if you ship a module and want to support the diverse ecosystem, it's a nightmare.
  - adev_ 7y ago
    > Nowadays I'm mildly annoyed if a project is on one of those "ancient" 3 but ≤3.6 Python versions and I can't use the nice features in 3.7+... No, it is a mess and it was a failure. It tooks more than 10 years to happen, and even so...Many tools will die with python2 and never be migrated. If your codebase is not usable anymore because your language evolved. That's a failure. I can still compile the C's from the 80's today if I want to. Same for Fortran, Same with C++.
    - mycall 7y ago
      Why wasn't more effort put into 2to3? That is the real failure.
      - adev_ 7y ago
        Because it's completely utopic to think that a conversion tool, even complex and well done could fix things like unicode handling. Unicode change between 2 and 3 cause behaviour change on your input/output and any serialisation. Even if your code could have been transpiled properly, the behaviour of your code would have still change, and still introducing bugs
mamcx 7y ago
I think this idea of "no broke compatibility"/"no rewrite" is never properly considering the presence of COST * TIME. In short time, is bad. The more time pass, is good. The cost of STUPID C/C++/JS behavior is measured in the billons. Is not the makers of this langs aware? Yes. They know how could be fixed? Sure. Then WHY is not fixed? Because not considering time in the calculation (and how many MILLONS OF PEOPLE are affect). But today, are DECADES behind of 100% certainty of the cost of this mistakes, and proved beyond doubts that the langs that fixed them ARE better. In the face of reality and facts, why resist so much? --- The thing is HOW get out of this mess? The big irony is that the JS world show how (but not commit with the proper force): Build transpilers. Make "Better C++" that transpile to "BAD C++". Make clear that everyone must move forward, but provide this as partial step. Make auto converters. Fix damm stupidity like dangling IFs, (seriously some stuff is not brainer). Have a clear vision in how move forward. And drop the ego. C/c++ not need to turn into Rust, but why believe it could not truly get better? Now, in the case of C/C++ exist a big trouble in the case of being the "de facto" ABIs for the rest of the world. Apple have the same issue with swift -> ob-c with the case of nullability (which apis never return null even if in theory could?). Them do annotations to the APIs. This could allow to mechanize the transformations and provide ABI translations that could be injected in the compiler. For example: ABI STEP 1 (annotate only): fn evil():NullableString //Imply NullableString = Option(Str) [safe(NullTerminatedString == Str)] fn not_evil(): NullableString Old code is assumed to be alike evil. ABI STEP 2 (rewrite): fn ex_evil():Option<Str> fn not_evil():Str Then it could autotranslate the calls in demand at compile time, following transformations alike maps. Eventually, when the calls are converted this step is erased and the runtime penalty removed, then all become good.
- NullPrefix 7y ago
  tl;dr but what's wrong with a new name?
  - _chris_ 7y ago
    My boss will never sign off on using a new language?
lanevorockz 7y ago
Better analogy would be Python 2/3. The language is the same with only binary incompatibility and a few very tiny semantic changes
captaincrowbar 7y ago
Obviously it should be called C+=2.
temac 7y ago
Or you would have the Ethernet situation: a new better tech that is called Ethernet while having mostly nothing to do with the old one, and people migrate to it, and the old tech is eventually not used anymore.
- deleted 7y ago
  [deleted]
- willio58 7y ago
  To follow in the footsteps of the Ethernet situation the new c++ would have to be better enough to make people switch, which I think is unlikely given the number of programs written in the current c++
- comex 7y ago
  Hardware has the difference that it eventually stops working and/or becomes obsolete, forcing people to migrate to newer models every so often. Code is immortal. Nevertheless, in Ethernet's case, while it changed backwards incompatibly at the beginning, since then, consumer Ethernet has been backwards compatible all the way from 1990's 10BASE-T (10Mbit) to the still-rare 10GBASE-T (10Gbit). In data centers you have faster variants that require different cables, for routers... but even there I believe the connections to individual servers typically use the old twisted pair.
MrBuddyCasino 7y ago
How about the JS "strict mode" model, that went pretty well? Default C++ is sloppy mode, new code can be strict via opt-in.
- Waterluvian 7y ago
  This works with supersets and I kind of love it. Like switching to Typescript. My code is just valid immediately. There's no migration downtime. And I chip away and one day it's all done and I disable "allow implicit any". Maybe that's what Python 3 should have done: don't remove stuff, but just make it discouraged and let a python3only" flag treat them as errors when ready. What we got was kind of a mess. Because python2 is very often valid python3... But not always.
- Too 7y ago
  In a way that's already available today with -Wall, Wextra -Weverything -Wevenmoreeverything -Wallforrealthistime, clang-tidy, MISRAC and various other static analyzers.
- einpoklum 7y ago
  Not good enough: 1. "New C++" would not just be a subset of the syntax of old C++. 2. ABI issues.

eternalny1 7y ago

I believe it's called Rust :)

The_rationalist 7y ago
Sadly rust lack some big features that c++ has like polymorphic inheritance, function overriding and function overloading.
- SaxonRobber 7y ago
  I think that is for the best. I prefer less implicit behaviour in my code, even if it means my identifiers get longer.
  - NotCamelCase 7y ago
    Rust doesn't have function/operator overloading yet or it won't have it at all? I am vastly for clarity and simplicity over vague, implicit stuff but doing e.g vector operations can get very unreadable very quickly without it.
    - pjmlp 7y ago
      Rust has operator overloading, https://doc.rust-lang.org/rust-by-example/trait/ops.html https://doc.rust-lang.org/rust-by-example/trait/ops.html
    - SaxonRobber 7y ago
      Vector operations are one of the few cases where I think operator overloading is sometimes a good idea.
  - adev_ 7y ago
    That's a design choice. Less implicit means safer but also more verbose and more cumbersome to write. Rust priorities safety over everything else, also over productivity too in some case. Absence of function overloading and automatic type conversion is a good example of that in Rust. Is it the right choice ? Only time and multi-million line codebase will tell us.
- the_why_of_y 7y ago
  Rust has "function overloading: the good parts" in the form of traits, inspired by Haskell's typeclasses. Rust does not provide the facility to strategically obfuscate code at scale like C++-style function overloading does.
Koshkin 7y ago
“fn... fn...” - No, that doesn’t sound like C++, at all.
- dtolnay 7y ago
  Fn is spelled differently than auto but it sounds more like C++ than you might think. // C++ auto f() -> int32_t { return 1; } // Rust fn f() -> i32 { return 1; }
- Iwan-Zotow 7y ago
  #define fn auto
  - Koshkin 7y ago
    Not a good idea: fn i = 0;
vaylian 7y ago
Rust is definitely a contender in the space. But philosophy-wise I think Walter Bright's D comes much closer.
zrm 7y ago
> I believe it's called Rust :) Yes, but no. When people design a language which they know is going to be incompatible, they tend to go all the way with it. If we're breaking it anyway then might as well do a better standard library interface than the stuff designed in the 90s and all that sort of thing, right? And that's good to have for new projects. But there is a benefit in having something which makes the smallest possible compatibility-breaking change to fix the defect in the original. So you have a "new language" with a borrow checker, but the standard library functions all have the same names and the same purpose and time complexity as the C and C++ ones, which would allow people to run the existing code through a transpiler which for 80% of the lines can be translated directly to working code in the new language, and produces diagnostic errors for the other 20% that explain what needs to be changed. Which removes 80% of the work from transitioning an existing codebase to the new language. And then more people do that.

rumanator 7y ago

> The C++ standards committee can standardize a backwards-incompatible "new" C++ for all I care as long as they don't call it C++. This x2. It's only C++ if you can optionally refactor random lines of code in a project written in compliance with C++98 using new features and still get a valid program. Once you mess with the language in a way that your C++98 code is either not supported or requires rewrites or redesigns to comply with the new standard then quite obviously it is not C++ anymore. Semver matters.

badsectoracula 7y ago
Under semver, they could call it "C++ 2.0" and be fine since according to semver anything with a major version change is free to break backwards compatibility.
- rumanator 7y ago
  The hypothetical C++2.0 would have less to do with C++ than C++ would have to do with C, and no one disputes they are entirely separate languages.
- paulryanrogers 7y ago
  While technically true so much of C++'s success is due to backward compatibility that I think the language would be instantly crippled. Java is in a similar situation, which is probably why they market the minor version.
  - pjmlp 7y ago
    Java and C++ have done several breaking changes, although not as bad as Python 3.0. The minor version for Java has stopped being used by Java 9.
    - heelix 7y ago
      Oracle calls the 6 month releases a 'major' version.. .but many corporate shops only care about the LTS versions (mostly 8 or 11) which are getting 90 day 'minor' patches. Java 11.0.6 is current till mid April, in which case 11.0.7 should hit. Our shops won't cut over to something beyond Java 11 until Java 17 (LTS version) hits in a few years. Just happy that we were able to make the jump from 8 to 11.

Fronzie 7y ago

C++ is deprecating things over time (https://en.cppreference.com/w/cpp/compiler_support https://en.cppreference.com/w/cpp/compiler_support), for example some uses of the volatile keyword (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1152r4.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p115...). So there is a path, but it has to take an upgrade-path into account for big legacy projects. In practice, moving to a new compiler can be a big project for companies with larger code bases. Sensible deprecation of features could (and in practice) is part of that. Even though the standard is quite careful, in practice big C++ projects sometimes rely on non-conforming behavior of the specific compiler version they use. An example is the MSVC template support which allowed constructs that the standard didn't.

rumanator 7y ago
> So there is a path, Your example is a really poor one. The volatile keyword was only used to provide hints to the compiler on whether or not it could apply some optimizations. Omiting a volatile keyword is perfectly backward compatible, as is compiling code without support for volstile. Thus the only practical consequence of adding/removing random volatile keywords from your source code was how your build could (and not should) be optimized. That's a far cry from, say, remove malloc().
- roca 7y ago
  Ignoring "volatile" would actually break a lot of code, because it's typically used where common optimizations must not be performed.
  - ncmncm 7y ago
    Formally ignoring or forbidding volatile where it presently doesn't mean anything (despite fervent wishing) wouldn't break anything. Compilers would of course continue supporting whatever they do, but would be allowed to warn about dodgy uses. On MSVC, volatile has traditionally meant something akin to atomic. It still will, regardless of what the Standard says and other compilers do.

coribuci 7y ago

> Then you'd just repeat the Perl 5/Raku split. You'd have a "new" C++ that isn't actually C++ but it's called C++ with a different version number and people will then bicker for a few years until they realize that the "new" C++ isn't actually C++ and that the "old" C++ just vehemently refuses to die, so they name it something else. Well, just FYI the "new" C++ is not the "old" C++ anymore. Languages "evolve". Try to compile an old program on the new compiler. The same is valid for other languages (C, fortran, perl). > The C++ standards committee can standardize a backwards-incompatible "new" C++ for all I care as long as they don't call it C++. They already do this. For C for example you have C89, C93, etc.

theamk 7y ago
Huh? Old programs on new compiler work with very minor changes and often with no changes at all. You might have to tweak some compiler flags, but this is per file. Your project can easily mix up C++ versions. Same for C - that old library in C89? Still usable in modern projects.
- pjmlp 7y ago
  Try to compile a library that uses gets() or K&R syntax in a C17 compiler.
  - AlexeyBrin 7y ago
    GCC 10 has no problem building C code that uses gets(), even with the -std=c17 compilation flag. You get a warning at runtime, but that's it.
    - pjmlp 7y ago
      GCC is one specific C compiler, it does not represent all of them.
      - theamk 7y ago
        Just checked on gotbolt.com - clangg, icc, msvc all compile gets just fine. They also work with k&r style definitions as well. I am sure there are broken C compilers out there which don’t implement entire language. Heck, I use one sometimes. But I don’t think this proves your point at all. You need better examples.

m463 7y ago

python 2 vs 3 is a mess too.

nnq 7y ago
?! Maybe was. A long transition... but it mostly happened already. Nowadays I'm mildly annoyed if a project is on one of those "ancient" 3 but ≤3.6 Python versions and I can't use the nice features in 3.7+...
- klyrs 7y ago
  I keep encountering backwards incompatibility between various flavors of Py3. It's a mess and if you have a large codebase, staying on top of the latest version is a nightmare. Or if you ship a module and want to support the diverse ecosystem, it's a nightmare.
- adev_ 7y ago
  > Nowadays I'm mildly annoyed if a project is on one of those "ancient" 3 but ≤3.6 Python versions and I can't use the nice features in 3.7+... No, it is a mess and it was a failure. It tooks more than 10 years to happen, and even so...Many tools will die with python2 and never be migrated. If your codebase is not usable anymore because your language evolved. That's a failure. I can still compile the C's from the 80's today if I want to. Same for Fortran, Same with C++.
  - mycall 7y ago
    Why wasn't more effort put into 2to3? That is the real failure.
    - adev_ 7y ago
      Because it's completely utopic to think that a conversion tool, even complex and well done could fix things like unicode handling. Unicode change between 2 and 3 cause behaviour change on your input/output and any serialisation. Even if your code could have been transpiled properly, the behaviour of your code would have still change, and still introducing bugs

mamcx 7y ago

I think this idea of "no broke compatibility"/"no rewrite" is never properly considering the presence of COST * TIME. In short time, is bad. The more time pass, is good. The cost of STUPID C/C++/JS behavior is measured in the billons. Is not the makers of this langs aware? Yes. They know how could be fixed? Sure. Then WHY is not fixed? Because not considering time in the calculation (and how many MILLONS OF PEOPLE are affect). But today, are DECADES behind of 100% certainty of the cost of this mistakes, and proved beyond doubts that the langs that fixed them ARE better. In the face of reality and facts, why resist so much? --- The thing is HOW get out of this mess? The big irony is that the JS world show how (but not commit with the proper force): Build transpilers. Make "Better C++" that transpile to "BAD C++". Make clear that everyone must move forward, but provide this as partial step. Make auto converters. Fix damm stupidity like dangling IFs, (seriously some stuff is not brainer). Have a clear vision in how move forward. And drop the ego. C/c++ not need to turn into Rust, but why believe it could not truly get better? Now, in the case of C/C++ exist a big trouble in the case of being the "de facto" ABIs for the rest of the world. Apple have the same issue with swift -> ob-c with the case of nullability (which apis never return null even if in theory could?). Them do annotations to the APIs. This could allow to mechanize the transformations and provide ABI translations that could be injected in the compiler. For example: ABI STEP 1 (annotate only): fn evil():NullableString //Imply NullableString = Option(Str) [safe(NullTerminatedString == Str)] fn not_evil(): NullableString Old code is assumed to be alike evil. ABI STEP 2 (rewrite): fn ex_evil():Option<Str> fn not_evil():Str Then it could autotranslate the calls in demand at compile time, following transformations alike maps. Eventually, when the calls are converted this step is erased and the runtime penalty removed, then all become good.

NullPrefix 7y ago
tl;dr but what's wrong with a new name?
- _chris_ 7y ago
  My boss will never sign off on using a new language?

lanevorockz 7y ago

Better analogy would be Python 2/3. The language is the same with only binary incompatibility and a few very tiny semantic changes

captaincrowbar 7y ago

Obviously it should be called C+=2.

temac 7y ago

Or you would have the Ethernet situation: a new better tech that is called Ethernet while having mostly nothing to do with the old one, and people migrate to it, and the old tech is eventually not used anymore.

deleted 7y ago
[deleted]
willio58 7y ago
To follow in the footsteps of the Ethernet situation the new c++ would have to be better enough to make people switch, which I think is unlikely given the number of programs written in the current c++
comex 7y ago
Hardware has the difference that it eventually stops working and/or becomes obsolete, forcing people to migrate to newer models every so often. Code is immortal. Nevertheless, in Ethernet's case, while it changed backwards incompatibly at the beginning, since then, consumer Ethernet has been backwards compatible all the way from 1990's 10BASE-T (10Mbit) to the still-rare 10GBASE-T (10Gbit). In data centers you have faster variants that require different cables, for routers... but even there I believe the connections to individual servers typically use the old twisted pair.

MrBuddyCasino 7y ago

How about the JS "strict mode" model, that went pretty well? Default C++ is sloppy mode, new code can be strict via opt-in.

Waterluvian 7y ago
This works with supersets and I kind of love it. Like switching to Typescript. My code is just valid immediately. There's no migration downtime. And I chip away and one day it's all done and I disable "allow implicit any". Maybe that's what Python 3 should have done: don't remove stuff, but just make it discouraged and let a python3only" flag treat them as errors when ready. What we got was kind of a mess. Because python2 is very often valid python3... But not always.
Too 7y ago
In a way that's already available today with -Wall, Wextra -Weverything -Wevenmoreeverything -Wallforrealthistime, clang-tidy, MISRAC and various other static analyzers.
einpoklum 7y ago
Not good enough: 1. "New C++" would not just be a subset of the syntax of old C++. 2. ABI issues.