C++ is a better C in the same way that a Cybertruck is a better bicycle.

Nah. More like C is a bunch of hand tools, and C++ is those same hand tools, plus a bunch of power tools. Sure, you could just use the hand tools, and hey maybe they even give you a better of sense of what you’re building at a low level, but it’s exhausting, and it turns out the power tools are really useful.

Some of C++ features are great, as recently discussed on the Linux kernel mailing list. However for many of Cs usecases, they are not appropriate, like exceptions and RAII in embedded. Once you start disabling major features those 'power tools' become far less attractive. Also, to extend the metaphor, hand tools are usually obvious and easy to use while power tools can have very long manuals. See for example the 275 page book on just Initilisation in C++ [0].

[0] https://www.cppstories.com/2022/cpp-init-book/

How is RAII a problem on embedded platforms? It is basically about scoped cleanup, something you would otherwise have to do manually.

Not sure what waa meant but what comes to mind to me who has dabbled in embedded is that in C it’s painfully clear how long “objects” live and when you tear them down and how. In C++ stuff can easily “happen” at an inopportune moment.

Same in C++: happens at the end of the scope. You precisely control where that is.

funny, but false.

the only sense in which the relationship between C & C++ is like that of a cybertruck to a bicycle is the one in which the latter are "transportation devices" and the former are "programming languages". there is no particular feature of a bicycle represented by a cybertruck other than "it gets you somewhere".

Yes, that's literally the point I was making.

Sure, but it's wrong. There's a ton of features of C present in C++. You might not like the C++ context they are present in, but it's nothing at all like the cybertruck/bicycle (non)relationship.

I guess some people are happy with a macro Assembler with a better syntax than MASM/TASM/NASM/yasm high level macros.

C++ and C are no longer used for the same types of projects so C++ is not a better C.

I think you must be from the 90s -- if so can you share your time machine?

All kinds of major projects switched to C++ already, for example GCC. All the major new projects, for example LLVM, are also in C++ from the get-go.

Even the Linux kernel is considering switching to C++ now.

> Even the Linux kernel is considering switching to C++ now.

Source?

I wonder if Linus has changed his views on C++ too in the mean time.

http://harmful.cat-v.org/software/c++/linus

A weird way to spell "Rust".

I giggled -- thank you.

No they’re not

> Even the Linux kernel is considering switching to C++ now.

considering doesn't mean it will happen in near future, because toolchains/ecosystem is not there, the same is applicable for many other projects.

I'm not aware of any toolchain limitations; making the kernel compile as C++ is doable with a few trivial patches, and the kernel already is heavily GCC-specific, which supports both C and C++ to the same level.

software is complex, and you can't be sure until you run it in mission critical production.

With the same argument you couldn't upgrade the compiler at all.

Thankfully the Linux kernel development relies on testing instead.

I have my doubts on c++ ever making it into the mainstream kernel while Torvalds is benevolent dictator. Especially since there is rust. I agree with the rest of what you said though.

Until C fixes its string and array story, C++ keeps being a better C.

I just use bstrlib... It's solid and works perfectly..

It is not part of ISO C and that is a big difference.

'just backporting [good] features' doesn't sound that bad when c++ is widely considered the most bloated mixture of the good, the bad and the ugly that there is.

Maybe the c++ killer will turn out to be just some future, modern version of C...

C++ is a different animal of a language. It is about compile-time meta-abstractions that generate a ton of invisible code under your feet. It has complex expression semantics and a crowded syntax space.

> that generate a ton of invisible code under your feet

Which is bad enough but there are plenty of cases where it may do this, or it may generate short obvious sequences of code, depending on more factors like compiler flags than you can easily observe while examining the line of code in question.

Hence the "as-if" rule, which helpfully applies in a lot of places, but not all, like return value optimization. I never felt like taking the time to build the kind of C++ confidence one must require to wield it correctly.

but this post is about c++ 23 and probably should stay on that topic? Everyone who uses c knows you can do it in c++ but either don't want to introduce the extra complexities, work with older code bases, prefer the "simplicity" of c, or have an organizational requirement. Personally on embedded I like c++, especially raii, smart pointers, containers, and classes, but I completely avoid rtti, exceptions, and complex template metaprogramming (by me). That subset is easy to keep in my head and on my projects. However some clients want C, and that's what I give them.