> the shared pointer implementation uses a POSIX mutex [...] C++’s shared pointer has the same problem

It doesn't. C++'s shared pointers use atomics, just like Rust's Arc does. There's no good reason (unless you have some very exotic requirements, into which I won't get into here) to implement shared pointers with mutexes. The implementation in the blog post here is just suboptimal.

(But it's true that C++ doesn't have Rust's equivalent of Rc, which means that if you just need a reference counted pointer then using std::shared_ptr is not a zero cost abstraction.)

The number of times I might want to write something in C and have it less likely to crash absolutely dwarfs the number of times I care about that code being cross-platform.

Sure, cross-platform is desirable, if there's no cost involved, and mandatory if you actually need it, but it's a "nice to have" most of the time, not a "needs this".

As for mutex overheads, yep, that's annoying, but really, how annoying ? Modern CPUs are fast. Very very fast. Personally I'm far more likely to use an os_unfair_lock_t than a pthread_mutex_t (see the previous point) which minimizes the locking to a memory barrier, but even if locking were slow, I think I'd prefer safe.

Rust is, I'm sure, great. It's not something I'm personally interested in getting involved with, but it's not necessary for C (or even this extra header) to do everything that Rust can do, for it to be an improvement on what is available.

There's simply too much out there written in C to say "just use Rust, or Swift, or ..." - too many libraries, too many resources, too many tutorials, etc. You pays your money and takes your choice.

I'd think a POSIX mutex--a standard API that I not only could implement anywhere, but which has already been implemented all over the place--is way more "cross platform" than use of atomics.

Thank you so much for sharing this. I missed the HN post.

This is beautiful!

Why would I want to run a garbage collector and deal with it's performance penalties?

It is surprisingly hard to find information about it, do you have any ? From what I can guess it's a new syntax but it's the feature itself is still an extension ?

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.

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.

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.

>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.

How can anyone be this interested in maintaining an annex k implementation when it's widely regarded as a design failure, specially the global constraint handler. There's a reason why most C toolchains don't support it.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm

That's the nice thing about macros, you can also have the macro generate C++ code using destructors instead of using the cleanup attribute. As long as your other C code is also valid C++ code, it should work.

MSVC now supports C17.

Given how C was seen in the past, before there was a change of heart to add C11/C17, minus atomics and aligned memory allocators (still between experimental or not going to happen),

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

https://devblogs.microsoft.com/cppblog/c11-atomics-in-visual...

https://learn.microsoft.com/en-us/cpp/c-runtime-library/comp...

And the new guidelines regarding the use of unsafe languages at Microsoft, I wouldn't bet waiting that it will ever happen, even after 2040.

https://azure.microsoft.com/en-us/blog/microsoft-azure-secur...

https://blogs.windows.com/windowsexperience/2024/11/19/windo...

Will windows be relevant by 2040? I personally don’t think so.

Bit of a random question on an article about C.

Fil-C essentially lifts C onto a managed, garbage-collected runtime. This is a small header that adds some C++ features to C.

(These features are still essentially unsafe: the unique pointer implementation still permits UAF, for example, because nothing prevents another thread from holding the pointer and failing to observe that it has been freed.)

Like the Linux kernel?

Macros are simply a fact of life in any decent-sized C codebase. The Linux kernel has some good guidance to try to keep it from getting out of hand but it is just something you have to learn to deal with.

Obligatory link to Bourne Shell source code. https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh...

Discussed here https://news.ycombinator.com/item?id=22191790

I think this can be fine if the header provides a clean abstraction with well-defined behaviour in C, effectively an EDSL. For an extreme example, it starts looking like a high-level language:

https://www.libcello.org/

It would be a lot more constructive if you reported a bunch of corner cases where this doesn't work rather than just dismissing this as a toy.

Yeah, kids like to waste time to make C more safe or bring C++ features. If you need them, use C++ or different language. Those examples make code look ugly and you are right, the corner cases.

If you need to cleanup stuff on early return paths, use goto.. Its nothing wrong with it, jump to end when you do all the cleanup and return. Temporary buffers? if they arent big, dont be afraid to use static char buf[64]; No need to waste time for malloc() and free. They are big? preallocate early and reallocate or work on chunk sizes. Simple and effective.

> Just don't use C for sending astronauts in space

But do use C to control nuclear reactors https://list.cea.fr/en/page/frama-c/

It's a lot easier to catch errors of omission in C than it is to catch unintended implicit behavior in C++.

> Just don't use C for sending astronauts in space. Simple.

Last time I checked, even SpaceX uses C to send astronauts to space...

I agree, if people just had refrained from building things in c/c++ that operated on data from across a security boundary we wouldn't be in this mess.

Some C devs will make all kinds of crazy efforts only not to use C++.

Actually C performs quite good in exactly that area.

https://ntrs.nasa.gov/citations/19950022400