Giving C a superpower: custom header file (safe_c.h)

C++: "look at what others must do to mimic a fraction of my power"

This is cute, but also I'm baffled as to why you would want to use macros to emulate c++. Nothing is stopping you from writing c-like c++ if that's what you like style wise.

Perhaps but a project using this stops you from writing any old C++ in your C. Writing C++ in a C style has no such protection.

It's choosing which features are allowed in.

It's interesting to me to see how easily you can reach a much safer C without adding _everything_ from C++ as a toy project. I really enjoyed the read!

Though yes, you should probably just write C-like C++ at that point, and the result sum types used made me chuckle in that regard because they were added with C++17. This person REALLY wants modern CPP features..

> I'm baffled as to why you would want to use macros to emulate c++.

I like the power of destructors (auto cleanup) and templates (generic containers). But I also want a language that I can parse. Like, at all.

C is pretty easy to parse. Quite a few annoying corner cases, some context sensitive stuff, but still pretty workable. C++ on the other hand? It’s mostly pick a frontend or the highway.

>Nothing is stopping you from writing c-like c++ if that's what you like style wise.

You'll just have to get used to the C++ community screaming at you that it's the wrong way to write C++ and that you should just use Go or Zig instead

Embedded CPU vendors not shipping C++ compilers is what usually stops people.

No name mangling by default, far simpler toolchain, no dependence on libstdc++, compiles faster, usable with TCC/chibicc (i.e. much more amenable to custom tooling, be it at the level of a lexer, parser, or full compiler).

C’s simplicity can be frustrating, but it’s an extremely hackable language thanks to that simplicity. Once you opt in to C++, even nominally, you lose that.

There was a language called clay that was C compatible but had move semantics, destructors, templates and operator overloading.

Yup. And I like the implication that Rust is 'cross platform', when it's 'tier 1' support consists of 2 architectures (x86 & arm64). I guess we're converging on a world where those 2 + riscv are all that matter to most people, but it's not yet a world where they are all that matter to all people.

[1] https://doc.rust-lang.org/beta/rustc/platform-support.html

The converging is happening in practice. I’m using a keyboard running RMK for firmware, written in Rust.

In my experience most chips released in the past 10+ years ship with C++ compilers.

Quite frankly I'm not sure why you wouldn't given that most are using GCC on common architectures. The chip vendor doesn't have to do any work unless they are working on an obscure architecture.

I highly doubt (and some quick checks seem to verify that) any of the tiny CC implementations will support the cleanup extension that most of this post's magic hinges upon.

(Agree on your other points for what it's worth.)

You are misunderstanding what Tiers are. Embedded architectures cannot be Tier 1 which requires running Rust compiler compiled on the architecture itself and testing stuff on with it. Only full desktop systems will be Tier 1, because those are the systems that you can run Rustc and all the nice desktop environments.

However most of the embedded world uses ARM chips and they are Tier 2 like thumbv6m and thumbv7em (there are still odd ones like 8051 or AVR or m68k, many of them lack a good C++ compiler already). They are guaranteed to be built and at the release time the tests still run for them.

If you have a pile of C, switching to using C++ is not easy.

TinyCC supports cleanup[1], onramp[2] supports C2y defer (which is a superset), slimcc[3] supports both.

[1] https://godbolt.org/z/hvj9vcncG

[2] https://github.com/ludocode/onramp

[3] https://github.com/fuhsnn/slimcc

I understand your tiers just fine. You are misunderstanding what "cross platform" means. Or rather, you're trying to redefine it to mean "what Rust supports, in the way we want to support it, on the few architectures we care about, because in our view nothing else of value exists".

However most of the embedded world uses ARM chips

My point exactly.