I wrote a summarizing article on type safe container types a while back, but
with some C23 specific changes and a few tweaks to work better for complex types.
I don't understand people reinventing macro-based hacks in C to achieve what was achieved in other languages many years ago. Why not using C++, for example? It's available almost everywhere, introducing its usage in an existing C codebase is pretty simple. Sure, C++ has its own downsides, but is it better to create mess with macros in C rather then using exiting language facilities and standard library containers provided by C++?
Having used C++ a lot in the past, I think the mess in C++ is way worse. I also contribute to projects that introduce C++ into a C code base, and I really wish they hadn't done this.
Although there are C features I like that I would need to remove before introducing C++ to a codebase, so this may not always be so simple.
What is mess in C++? Yes, it has some shady parts and is more complex than C, but this complexity provides expressiveness and type safety. And you can always use only features from C++ you find useful.
> also contribute to projects that introduce C++ into a C code base, and I really wish they hadn't done this.
What is problematic in these projects other than unfamiliarity of C++ for developers previously used only C?
How do you make a shallow copy of an object in C++, how do you do the same thing in C? Knowing I can just memcpy _any_ struct in C and have a valid shallow copy is pretty huge.
How do you create a stable ABI in C++? How do you make one in C? In C, knowing that all my exported functions will mostly just work and be stable as long as I don’t change the interface is also huge and allows you to create cross language bindings pretty trivially.
You can’t necessarily do that in C either, it depends on if your object is in a container that relies on pointer stability. Intrusive linked lists are common in C and they get broken by this, for example.
> How do you make a shallow copy of an object in C++
Shallow copies aren't generally possible for classes storing something indirectly, since it violates ownership semantics. That's not how things are done in C++.. Operator = is usually used for making copies, which is optimized to memcpy for POD structures, but for something more complex may perform extra work for doing an actual deep copy.
> How do you create a stable ABI in C++
It's a complex topic. Basic ABI for calling functions is identical to C. But one need to keep in mind, that type layouts and internal implementations of library types (like containers) may differ from implementation to implementation and from version to version.
> knowing that all my exported functions will mostly just work and be stable as long as I don’t change the interface
Nothing prevents you doing this in C++. You can have C-style external interface and use all goods of C++ internally.
You left out the part of my comment where I said “pretty trivially” lol. C++ is mostly a superset of C, which is why I’m not arguing that it’s impossible to do these things in C++. I like C++ too, and think some of the things in there are great. But the simplicity of C is nice. I would often get overwhelmed thinking about all the different constructors in C++ and what I needed to do to ensure that I didn’t accidentally tank performance by copying objects around everywhere (and potentially calling some invisible constructor that did extra work in the copy function). In C, I know when I memcpy it’s just gonna move some bytes around.
Overall, I really don’t care all that much one way or the other. But I can see how people could prefer C to C++. I could also see how people prefer C++. I really really miss function overloading and <string.h> when I use C
You seem to be asking question "why people use hacks in C instead of coding in other languages which are more C++ like". Then you describe what is to be C++ like. Well, maybe the issue is that certain people precisely want to avoid the features you just described. Have you considered that?
Calling memcpy on any random old struct in C is how you get bugs. If the struct contains other pointers: who is in charge of freeing them? What if the struct has internal pointers (a pointer pointing to a subobject of the struct)? You are playing with fire and you know it.
As if C programmers don’t have to be disciplined. Look if you are a C programmer you need to pick good parts of the language to write in as well. A beginner picked gets()? Oh the foes of the young and inexperienced. You picked VLA? Linus would breathe fire unto you.
A difference between C++ programmers and C programmers is that C++ programmers have the awareness to know their language has bad parts to avoid, but C programmers are oblivious to the bad parts until someone uses it, but otherwise sing paeans for the language.
In C, assigning the return value from malloc() to a specific type merely produces a warning:
$ echo -ne "#include <stdlib.h>\nint foo() { return malloc(42); }" | gcc -xc -fsyntax-only -c -
<stdin>: In function ‘foo’:
<stdin>:2:20: warning: returning ‘void *’ from a function with return type ‘int’ makes integer from pointer without a cast [-Wint-conversion]
Whereas in C++ it's a hard error:
$ echo -ne "#include <stdlib.h>\nint foo() { return malloc(42); }" | gcc -xc++ -fsyntax-only -c -
<stdin>: In function ‘int foo()’:
<stdin>:2:26: error: invalid conversion from ‘void*’ to ‘int’ [-fpermissive]
In both languages this is a constraint violation, and it is fully at the discretion of the compiler on whether it emits a warning or error (often controllable by compiler flags). For my C compiler (GCC) this is an error.
No, this counts as C++ is stupid to me. The memory returned by malloc is UNTYPED. The sole reason why void as a type exists is to convey the notion of no type, so that it needs to be assigned to a type by a programmer. If you mean "byte region, please cast before use" that's 'char *'. Since C++ now forces me to write a cast, it effectively forces me to hide and silence errors.
I do want an error when I violate types, I do not want it for void, because that's the whole meaning of void. C++ manages to make it the worst of both worlds.
Nah. Malloc’s return type is a pointer. The memory pointed to by a malloc call is untyped. But the return type isn’t void. It’s void*, aka a pointer to unknown.
I’m mostly happy with implicit casts from void* to int* or something. But in this code example, we see an implicit cast from void* to int, casting the pointer itself into a number that might not even fit the pointer. This is rarely what you want. I’d much rather explicit casts in this case.
My understanding is that C has a different understanding of the word warning than other languages. Such as in "stern warning" or "warning: the building will collapse if you take that brick out".
This is a philosophical problem. C has false positives to the question: "Is that a program", and some people find that to be idiotic (I don't, this is why I like C). But this becomes really logical, when you have in mind, that the point is that you do not want to have false negatives.
What version is your compiler? As of GCC 14 and clang 15 an implicit pointer conversion to int is an error, not merely a warning; and this is without specifying any special conformance or warning modes. I think implicit int conversions have been a constraint violation since at least C99, requiring a diagnostic, though I'm not sure if the switch to an error instead of a warning was prompted by a change in wording in C23 or just a general change in attitude and less concern with failing on pre-existing (but wrong) code.
This was GCC 11. I did try clang 15 and got an error (whereas 14 did not), but my point was that the language spec itself allows this, regardless of any specific compiler, and the original argument (as I understood it) was about the type safety of C and C++ (the language specs) themselves.
I'm not very familiar with the C++ standard, but I don't think the C++ standard requires compilation to fail, either. It has similar language to the C standard. Per C++23 4.1.1p2.3,
> Otherwise, if a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
The C++ standard does seem to explicitly require the compiler to reject translation units with a failed static_assert. (The requirements for #error are a little confusing; not sure if a failed #error in a conditional block requires failure.) But I couldn't find a rule that mandates failure for invalid implicit int conversions. Implicit pointer to int conversions are invalid for the same reasons in both C and C++. Basically, AFAICT C++'s type safety in this regard is a matter of historical compiler behavior, and now the major C compilers are adopting that behavior, which they previously had allowed (with a mandatory diagnostic message) for backward compatibility reasons.
If C++ adds pattern matching, and it works in practical usage across projects, will the C ecosystem consider adding some kind of pattern matching, perhaps inspired by what comes into C++, perhaps not?
Also, a question for a C expert like you, uecker: In your opinion, does the compound literals feature have complex lifetimes rules or complex semantic rules otherwise?
Personally, I would like to have pattern matching, but I think we need some other features first. I am usually a bit scared about what C++ comes up with.
I am not sure I understand the second question. I do not think compound literals have complex lifetime rules. The lifetime end with the corresponding block, as do other objects in C (one needs to know what a block is, some people confuse this with scope). There is some potential issue which may be surprising when passing them to macros that make use of the statement expression extension, as the lifetime is then limited to the macro body.
I have read up on it, and I do not remember why I arrived at the conclusion that compound literals have complex rules. Their rules are different from C++ and Rust temporaries, but the rules of compound literals are not complex, though their block lifetimes do have to be understood. I have seen at least two C developers being confused about their lifetimes (mostly about when used inside if-statement's condition or in a loop), but most C developers seem to grasp compound literals and their lifetime quickly, and the cppreference.com page is relatively short, which reflects the simplicity of compound literals. It helps that one can understand them as a local variable, local to the specific block that they are used in.
For one reason, it is because C++ runtime (and its standard library) is a whole own can of worms which most people would rather not touch if they can afford to. Which they mostly can.
> Sure, C++ has its own downsides
"Sure, getting your eyes gouged out has its downsides, but is it better to read that awful mess of macros in C instead?" The answer most people would give to this question may surprise you.
Here we go again. Yes there are bad parts in the C++ standard library and there are good parts. But if you are just trying to do type safe generic data structures you are unlikely to touch the bad parts. Many codebases forbids parts of the standard library, e.g. LLVM forbids including <iostream>. You can forbid using parts of the standard library too.
> Yes there are bad parts in the C++ standard library and there are good parts.
Okay, other than <vector>, what are the good parts? Because as the sibling comments rightfully point out, migrating your codebase from C to C++ just to be able to use <vector> is not worth it.
The <map> is a sad joke played upon the C++ programmers by the standard committee.
Exactly, and a simple usable string type is just a struct MyString { char *buf; size_t len; }; away. Actual magic is in how you use it, where you allocate it, how you integrate allocation and formatting and logging and I/O... i.e. all the things that aren't solved by crufty complex std::string either.
The projects and people I follow do this all the time. Just like putting a size field near each regular non sentinel terminated array is useful. But if not doing it (maybe linux kernel in many cases), no big deal either, don't sweat the small stuff. String slices are small and rarely perf critical.
It's a slow generic data structure with an unintuitive API. You can use it for leetcode or for CRUD. For anything more demanding it's horrifically bloated and bad. std::string too. Whenever you see STL datatypes like even string and map, you have to deal with RAII, implicit allocations, weird operator syntax, unexpected mutation (invalidation) and so on.
(Spporting or even encouraging destructive mutation, and by this I mean not incrementing counters or anything harmless but allowing iterator invalidations and crashes, are also why std::vector is bad in my opinion, these are idiomatic APIs for 90s and 2000s programming, which we should know better to avoid in 2026).
> For anything more demanding it's horrifically bloated and bad
C++ containers are designed for average demands. If you need something more specific, you can always use an alternative implementation. And it's better than messing with macros in pure C.
> you have to deal with RAII
What's problematic with it?
> implicit allocations
Allocations aren't implicit. It's usually clear from the documentation where allocation takes place (like in concatenating strings or copying strings).
> unexpected mutation (invalidation)
It's not the case with standard library containers. Mutating methods aren't const-qualified, so that it's clear where mutation can take place. And in C++ it's strictly recommended to mark as const everything in regular user code which shouldn't be mutated.
> C++ containers are designed for average demands. If you need something more specific, you can always use an alternative implementation.
As someone who has been programming exclusively in C/C++ for a long time -- the biggest selling point for these languages in 2026 is exactly being suited to doing something specific, not generic.
> Allocations aren't implicit
std::map<int,int> m;
m[1] = 42; // implicit alloc
auto m2 = m; // implicit too
> in C++ it's strictly recommended to mark as const everything in regular user code which shouldn't be mutated.
Theory and practice. Making everything const correct is too painful in practice, often impossible. It's a trap for bean counters that can't focus on getting some actual useful work done. I'm being harsh to my own past self here. Counter question: why include allocation mechanics with some existing data that never gets changed? Why should we have to add much more boilerplate to get the simpler thing?
operator[] of associative containers is mutating and may allocate. It's mentioned in the documentation. And there is no operator[] overloading for const instances, so that you can't trigger an allocation by just reading elements from it.
> auto m2 = m; // implicit too
Taking a copy requires making an allocation. Do you expect some other behavior in such case?
> Making everything const correct is too painful in practice, often impossible
Maybe you are dealing with some legacy codebase (from 90s)? I have worked with multiple codebases in past 10 years or so and keeping things which shouldn't be mutated const wasn't a problem at all. All the code was written using such approach.
> why include allocation mechanics with some existing data that never gets changed
I don't think I fully understand this question. What never gets changed? In your example you are mutating a container and taking a copy of it (which can be changed later).
> auto m2 = m; // implicit too
Taking a copy requires making an allocation.
C++ makes it “look nice” at the cost of clarity. But not consistently. Overall, despite addition of syntax sugar in various places to make things look smooth, we arguably have “a lot of syntax” (“syntax castles”) in C++, as a result of embracing a lot of complexity. C, OTOH, avoids both sugar and castles.
No, just saying this stuff is implicit and thus hard to read. More so the allocation on indexing assignment.
and keeping things which shouldn't be mutated const wasn't a problem at all.
> and keeping things which shouldn't be mutated const wasn't a problem at all.
As soon as datastructures become more complicated and more interconnected, it's not clear anymore what const should even mean (issues are similar as with deep vs shallow copies, how do you even draw the lines, where are the objects?).
And the major philosophical flaw in the const vs. non-const distinction is that to make a strict separation you have to move everything mutable into constructor calls (for the most part, not getting more into the weeds of C++). Which is very awkward, it's a real tradeoff you need to be aware of. I realized only after playing these games for a long time what a waste of time it is and how much complexity it creates.
Great that setjmp/longjmp is explicit, and that in C there are even more liberties to cast away const than in C++, while some surprises in embedded, when the compiler decides const could have been placed into read only memory.
Placing data in .rodata (read only memory) is an actual useful application of const keyword. Not specific to embedded. Arguably there shouldn't have been multiple slightly different meanings of the keyword like that.
I don't know why you are now jumping to setjmp/longjmp, trying to make a point that somehow C is the worst programming languages ever, when all I am trying to argue is for sane programming practices, hinting that more complex features (line especially found in newer languages) are not solutions but part of the complexity problem.
You must be very experienced to be so judgemental! But maybe ask the many billions of voxels that get tested per second on my multithreaded and SIMD'ed cutting simulation.
C++ is the best language to write multi-architecture SIMD without relying on compiler magics like autovectorization. It gives you enough tools to define zero-cost abstractions to make SIMD nice.
Yeah... There are libraries like Google Highway but that seems to me like a bulky software abstraction layer even if it is a so-called "zero cost" abstraction. Maybe appropriate in some cases. In my case, I've implemented a couple of lines for AVX2 and AVX512, maybe around 100 lines for the most perf sensitive sections currently, not a big deal. The actual work is in the understanding of the problem and of the phyiscal hardware, and in the software architecture and data layout to even enable vectorized stream processing in the first place. I'm not concerned writing a couple of perf sensitive lines against 2-3 most important concrete vector ISAs. I also fancy adding a GPU backend later (requires D3D12/SM6.0 API level), Highway couldn't help with that.
RAII is terrible for memory resources - it's ok for things like locks I guess.
Rarely do I want to couple initialization with allocation, I want bulk allocations/deallocations (and I want precise control over when that happens) and reset()-like functions so I can easily reuse memory.
It couples things and complicates things. Which creates friction against when refactoring a software architecture, making it harder to scale it up.
Fully agree, for locks or other simple begin/end pairs it doesn't create the same kind of architectural damage. But I don't use it even there, because RAII fundamentally doesn't play well with manual cleanup code. It's kind of an all-in game, if you use some RAII there are strong forces (whenever you need to get the "nesting" right) to convert all remaining manual begin/end type code to types that define that functionality out-of-line in the destructor/destructor, leading to fragmentation.
At least is there in the standard library, one doesn't need to invent one from scratch in every single project, or reach out to the tools floppy while not telling the employer due to code ownership.
No need to invent when you already know how it works.
I could re-type all the essential stuff from std::string that I've ever used myself within 10 minutes, no problem, without looking up external sources, including copy & move semantics and whatnot. But I'm deliberately not doing it. Because I don't like this "invention".
So what? You like <vector>, and make it the only allowed include. Write all other type safe generic data structures by hand using C++ syntax. Problem solved. In fact many old codebases migrated from C already has their own implementations of strings and vectors and hash tables, so these projects can totally forbid the C++ standard library versions in favor of their own versions, and only pull in <type_traits> for easier type safe generic data structure programming.
In my personal opinion, the fix[1] for that issue clearly implicates C-style habits polluting a C++ code base. No right-thinking knower of C++ initializes objects with memset! Also I believe that -Wall would have flagged that, and I know for certain that cppcoreguidelines-init-variables + cppcoreguidelines-pro-type-member-init would have flagged it.
Its rather hard to introduce c++ into legacy c projects. You basically have to decide on a subset of features to use, and then you'll have to explain to the teams why the same looking code now takes 10x more compute to build.
Usually the way we do it here is we honor some interface then rewrite the subsystem in c++.
And then there's the real hurdle and that is getting the c++ idiom correct as it is very easy to just open the floodgates and let everyone write code that looks vastly different.
Not sure why author does it, but I use C over C++ for one reason: I'd rather not have random hidden malloc() scattered in my code. And no, it's not about latency or performance. Once my code takes an yet unexplored part and runs out of 200kB RAM, the will be no way for me to learn about it - running out of memory will bring down both the logger and the radio link, which is the only way to get the logs from a sensor installed twenty meters above ground in a hazardous environment facility. C may be unsafe, but most errors short of "writing to a random memory area" are either well-contained or at least reproducible. Dynamic memory allocation means that anything may crash everything. Manageable if you have a MMU and can contain crashes within isolated heap, but if not - I'd rather not bother. And yea, you can write zero-allocation C++ code, but why bother if most of STL is now unusable? And you get some new and exciting UB modes (seriously, no union aliasing, what the heck?)
Also, template metaprogramming is way more arcane than C macros. And I need compile-time metaprogramming in leu of dynamic allocation. So C macros it is for now (Zig is promising but still not there yet).
These macro tricks (from the article) are not about recreating C++ in C.
C is less opinionated (comp. to C++): it gives you fewer built-in abstractions; does not prescribe which DS dev. should use. It is bring-your-own-data-structures language. Bring whatever you choose.
In C, newer language standard is not always better. Older lang standards support more platforms. There is a certain beauty in writing in an old language while still applying modern coding practices.
I like C. I don't hate other languages. I wouldn't use C for apps that should have been written in C# with WinForms...
You definitely should add a detailed post on your "DrC" compiler/interpreter; usecase, scope, techniques used etc. Since this is looking forward to C2y/C29 with some more extensions, i think people will enjoy playing with it in the REPL format.
I agree. Alas I have a day job and my other hobby is going for long hikes. But when the days get shorter and the weather is worse I’ll write some more!
Lol at some point just implement a small compiler in C… reflection is kinda a hilarious thing to have like I understand the use case for generics, since it's not that that that hard to do with macros and quite commonly wished for
It's somewhat of a forced trick nowadays, I think.
I actually thought from the title before I read the article that it was going to use _Generic, as in something like _Generic((item),__typeof__((list)->payload):...) .
It's not worth it. The value of C is in compatibility, availability of compilers, and familiarity.
As soon as you change anything in a breaking way, start requiring your own compiler/transpiler, or introduce new idioms, you end up losing the things that keep C alive.
Users of C either like it exactly the way it is, or have to use a specific C version due to a vendor dependency or compliance.
An upgraded C not approved by the standards body gives you yet another niche language that is not C, but is still burdened with its old flaws.
I really don't understand why people bring up other languages when one is discussing implementation of some "advanced/tricky/hackish/new" features in C. It is not as if the implementer does not know about the ease of availability in other languages but there is always some set of criteria which prevents switching to a new language.
On a related note, there is a dearth of written/learning material (books etc.) cataloging and explaining advanced architecture/design/implementation patterns in C though we know they exist in the tons of industrial-strength codebases out there.
There is also the fact that when you see an implementation in C of some feature from another language you better understand language design pragmatics eg. implementing inheritance and virtual functions in C gives you insight into how they work in C++/Java/C#/etc.
It would be nice to have something like C which was very much like C and Pascal (not the syntax) but which was basically C except no naked pointers by default etc, fewer footguns, but which would generate C.
mrustc generates (ugly) C from Rust. And doesn't borrow check or otherwise add any bounds checks. It only supports the parts of Rust that the Rust compiler itself needs, but that's quite a lot of it.
I am working on a language that was C with extensions, transpiled to plain C, but the C syntax is kinda not great to work with (stuff like needing type tables and unbounded lookahead). At the point you clean up the syntax, you're not really C with extensions anymore.
I mean you dont need to make a "language" at all, you can just write a librar for all the stuff you need. This stuff is just syntactic sugar.
For example, when I worked on writing embedded software for autopilots, we had 2 files, common.so and common.h that contained essentially a super robust typing framework. The way it worked is that you defined types through the provided functions at the beginning of your code, and all of the definitions were stored and checked at runtime at the beginning before the main execution loop took effect. So basically taking what a more robust language compiler would do and just moving that processing to the start of execution.
I use something similar for my local llm setup at home, where i can have my agent basically write tools for itself and when the tool fails, the error code makes it pretty easy for the agent to fix.
VLAs are anti C. I also dont even think _Generics should be in the complier. The complier should do minimal processing of syntax in terms of decision making, with only focus on being optimizing code.
Because in the flip side, you get C++ templates, which are turing complete, so you can write entire program syntax that the compliler executies during the complie process.
I do not get the connection with a VLA in this context, but if you need a VLA, by all means use it. It is basically always better than the alternative.
I see. This array of unknown length at the end of a struct is called a flexible array member and not a variable length array (although it also refers to an array of variable length it is a different language feature).
VLAs are supported by basically all modern C compilers though, and I do not think adding them was a mistake (I certainly use them a lot!). They got a bad reputation due to stack clash attacks, but in the past some compilers did not implement stack probing (clang was very late). But this was fixed a decade ago.
I just want C with classes, like C++ started out as.
What I'd really like is a standards-conformant (C++98/03) compiler that actually enforces the standard properly (or maybe it becomes a new standard), and ONLY allows that version to be used, AND only the classes.
No templates, no exceptions, no standard library (just use a plain libc).
I absolutely cannot remember the details, but we did typesafe, macro based generic data structures in C in an undergrad class I took ~20 years ago (CMU Operating Systems). The idea has definitely been around, though I don't know if the implantation was the same.
The difference between me and you is that I do not usually post under C++ articles something negative about C++. Instead I respect that people interested in C++ may have their own reasons. For some reason you find it appropriate to post something negative under each C article.
I could tolerate it if it were at least some interesting criticism,.
Because I find a waste of time to insist in pushing C, with all its flaws, into the industry.
Microsoft, Google, Apple and co have done the right decision regarding to what extent C is still required on their platforms, when we have Typescript for C for about 40 years.
Now if WG14 was actually doing type safe enumerations, sorting out implicit conversations and arrays decaying into pointers only to save typing 4 additionally characters per location, catching up to PL/I strings and arrays, I might be a bit more positive.
One can wait for WG14 to ever deliver that, assuming it will ever happen, or take the easier way out, and use such features on C++ today.
In reality, we as industry should have long replaced both of them with something better, since Ada and Modula-2 came to be, but alas the industry always takes the easier path, like mountain rivers.
Yes, but please take your general grievances about than Pascal / Modula / Ada did not win elsewhere than to every discussion related to C. Maybe write a nice Modula program and make submission aoub this?
I've tried doing this for a few years and it just sucks ass. Just use c++ and templates if you need proper generic data structures. C is a defective language.
Problems with lead: it's toxic and it accumulates, lead doesn't leave you and builds up over time. It's not just toxic in the sense that too much will kill you, but even small quantities can cause nerve and brain damage, among other things. It is easier for your body to absorb lead than many other elements.
My comment was pointing out that despite lead being known for millennia as a problem in people, it was used for:
* water delivery pipes
* plates and cutlery and cups
* a paint ingredient in everyone's home
* a sealant
* a fuel additive that was spewed into the air by every motor vehical
* a lubricant in a lot of machinery
* a common additive to many additional products all over the place
* a common additive in industrial processes leaving lead residue on products that wouldn't otherwise contain lead.
So the phrase: "underpins most of the technology in the world" somewhat realistically applies to lead - in the early 1900s it was everywhere all the time.
And as i pointed out at the start of this - it is kind of a bad choice to be using all the time in everything since it causes so many problems for people. Humanity has been dramatically reducing the use of lead in everything for a long time now (decades) and will continue to do so for a long time. The bad effects of all the lead use during the industrialization of our species will remain for quite a while.
So my whole point was: just because something was used in the creation of great outcomes, it doesn't make it any good in a fundamental way. I'm saying C is like lead in my analogy.
Never gonna happen. As soon as you kill it off, someone's going to realize they need a very minimal fast "unsafe" language for something, and reinvent C, probably poorly
I think it is a pretty good language. Simple, elegant, performant, stable, and fun to write. Most programs I like for being efficient, non-bloated and reliable turn out to be written in C.
I wrote a summarizing article on type safe container types a while back, but with some C23 specific changes and a few tweaks to work better for complex types.
https://louissven.xyz/article/how_I_do_container_types_in_C....
Feel free to flag/delete if this isn't the place.
Thanks for sharing.
It is really nice that you studied both Martin Uecker and Daniel Hooper's techniques and tweaked them to suit your ideas/taste.
I don't understand people reinventing macro-based hacks in C to achieve what was achieved in other languages many years ago. Why not using C++, for example? It's available almost everywhere, introducing its usage in an existing C codebase is pretty simple. Sure, C++ has its own downsides, but is it better to create mess with macros in C rather then using exiting language facilities and standard library containers provided by C++?
Having used C++ a lot in the past, I think the mess in C++ is way worse. I also contribute to projects that introduce C++ into a C code base, and I really wish they hadn't done this.
Although there are C features I like that I would need to remove before introducing C++ to a codebase, so this may not always be so simple.
> the mess in C++ is way worse
What is mess in C++? Yes, it has some shady parts and is more complex than C, but this complexity provides expressiveness and type safety. And you can always use only features from C++ you find useful.
> also contribute to projects that introduce C++ into a C code base, and I really wish they hadn't done this.
What is problematic in these projects other than unfamiliarity of C++ for developers previously used only C?
> What is mess in C++?
Just a couple examples:
How do you make a shallow copy of an object in C++, how do you do the same thing in C? Knowing I can just memcpy _any_ struct in C and have a valid shallow copy is pretty huge.
How do you create a stable ABI in C++? How do you make one in C? In C, knowing that all my exported functions will mostly just work and be stable as long as I don’t change the interface is also huge and allows you to create cross language bindings pretty trivially.
You can’t necessarily do that in C either, it depends on if your object is in a container that relies on pointer stability. Intrusive linked lists are common in C and they get broken by this, for example.
> How do you make a shallow copy of an object in C++
Shallow copies aren't generally possible for classes storing something indirectly, since it violates ownership semantics. That's not how things are done in C++.. Operator = is usually used for making copies, which is optimized to memcpy for POD structures, but for something more complex may perform extra work for doing an actual deep copy.
> How do you create a stable ABI in C++
It's a complex topic. Basic ABI for calling functions is identical to C. But one need to keep in mind, that type layouts and internal implementations of library types (like containers) may differ from implementation to implementation and from version to version.
> knowing that all my exported functions will mostly just work and be stable as long as I don’t change the interface
Nothing prevents you doing this in C++. You can have C-style external interface and use all goods of C++ internally.
Yeah, and that's the reason why people prefer to write in C.
"That's not how things are done in C++" I like C, because I can just decide for myself how things are done here.
> Nothing prevents you doing this in C++.
You left out the part of my comment where I said “pretty trivially” lol. C++ is mostly a superset of C, which is why I’m not arguing that it’s impossible to do these things in C++. I like C++ too, and think some of the things in there are great. But the simplicity of C is nice. I would often get overwhelmed thinking about all the different constructors in C++ and what I needed to do to ensure that I didn’t accidentally tank performance by copying objects around everywhere (and potentially calling some invisible constructor that did extra work in the copy function). In C, I know when I memcpy it’s just gonna move some bytes around.
Overall, I really don’t care all that much one way or the other. But I can see how people could prefer C to C++. I could also see how people prefer C++. I really really miss function overloading and <string.h> when I use C
You seem to be asking question "why people use hacks in C instead of coding in other languages which are more C++ like". Then you describe what is to be C++ like. Well, maybe the issue is that certain people precisely want to avoid the features you just described. Have you considered that?
QED.
Calling memcpy on any random old struct in C is how you get bugs. If the struct contains other pointers: who is in charge of freeing them? What if the struct has internal pointers (a pointer pointing to a subobject of the struct)? You are playing with fire and you know it.
> And you can always use only features from C++ you find useful.
Ah, the old "programmers just need to be more disciplined when using C++".
Yeah, C programmers have never seen that argument before...
As if C programmers don’t have to be disciplined. Look if you are a C programmer you need to pick good parts of the language to write in as well. A beginner picked gets()? Oh the foes of the young and inexperienced. You picked VLA? Linus would breathe fire unto you.
A difference between C++ programmers and C programmers is that C++ programmers have the awareness to know their language has bad parts to avoid, but C programmers are oblivious to the bad parts until someone uses it, but otherwise sing paeans for the language.
> A beginner picked gets()?
Nitpick: that isn’t possible anymore. gets was removed from C in C11 (https://en.cppreference.com/c/io/gets)
My macro-vector types are type safe. In fact this is the point.
I do not think C++ is more expressive or type safe.
In C, assigning the return value from malloc() to a specific type merely produces a warning:
Whereas in C++ it's a hard error: Does this not count as "more type safe" to you?In both languages this is a constraint violation, and it is fully at the discretion of the compiler on whether it emits a warning or error (often controllable by compiler flags). For my C compiler (GCC) this is an error.
No, this counts as C++ is stupid to me. The memory returned by malloc is UNTYPED. The sole reason why void as a type exists is to convey the notion of no type, so that it needs to be assigned to a type by a programmer. If you mean "byte region, please cast before use" that's 'char *'. Since C++ now forces me to write a cast, it effectively forces me to hide and silence errors.
I do want an error when I violate types, I do not want it for void, because that's the whole meaning of void. C++ manages to make it the worst of both worlds.
Nah. Malloc’s return type is a pointer. The memory pointed to by a malloc call is untyped. But the return type isn’t void. It’s void*, aka a pointer to unknown.
I’m mostly happy with implicit casts from void* to int* or something. But in this code example, we see an implicit cast from void* to int, casting the pointer itself into a number that might not even fit the pointer. This is rarely what you want. I’d much rather explicit casts in this case.
You're right, I failed at reading comprehension.
My understanding is that C has a different understanding of the word warning than other languages. Such as in "stern warning" or "warning: the building will collapse if you take that brick out".
This is a philosophical problem. C has false positives to the question: "Is that a program", and some people find that to be idiotic (I don't, this is why I like C). But this becomes really logical, when you have in mind, that the point is that you do not want to have false negatives.
What version is your compiler? As of GCC 14 and clang 15 an implicit pointer conversion to int is an error, not merely a warning; and this is without specifying any special conformance or warning modes. I think implicit int conversions have been a constraint violation since at least C99, requiring a diagnostic, though I'm not sure if the switch to an error instead of a warning was prompted by a change in wording in C23 or just a general change in attitude and less concern with failing on pre-existing (but wrong) code.
This was GCC 11. I did try clang 15 and got an error (whereas 14 did not), but my point was that the language spec itself allows this, regardless of any specific compiler, and the original argument (as I understood it) was about the type safety of C and C++ (the language specs) themselves.
I'm not very familiar with the C++ standard, but I don't think the C++ standard requires compilation to fail, either. It has similar language to the C standard. Per C++23 4.1.1p2.3,
> Otherwise, if a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
The C++ standard does seem to explicitly require the compiler to reject translation units with a failed static_assert. (The requirements for #error are a little confusing; not sure if a failed #error in a conditional block requires failure.) But I couldn't find a rule that mandates failure for invalid implicit int conversions. Implicit pointer to int conversions are invalid for the same reasons in both C and C++. Basically, AFAICT C++'s type safety in this regard is a matter of historical compiler behavior, and now the major C compilers are adopting that behavior, which they previously had allowed (with a mandatory diagnostic message) for backward compatibility reasons.
If C++ adds pattern matching, and it works in practical usage across projects, will the C ecosystem consider adding some kind of pattern matching, perhaps inspired by what comes into C++, perhaps not?
Also, a question for a C expert like you, uecker: In your opinion, does the compound literals feature have complex lifetimes rules or complex semantic rules otherwise?
Personally, I would like to have pattern matching, but I think we need some other features first. I am usually a bit scared about what C++ comes up with.
I am not sure I understand the second question. I do not think compound literals have complex lifetime rules. The lifetime end with the corresponding block, as do other objects in C (one needs to know what a block is, some people confuse this with scope). There is some potential issue which may be surprising when passing them to macros that make use of the statement expression extension, as the lifetime is then limited to the macro body.
Thank you very much, that helps a lot.
I have read up on it, and I do not remember why I arrived at the conclusion that compound literals have complex rules. Their rules are different from C++ and Rust temporaries, but the rules of compound literals are not complex, though their block lifetimes do have to be understood. I have seen at least two C developers being confused about their lifetimes (mostly about when used inside if-statement's condition or in a loop), but most C developers seem to grasp compound literals and their lifetime quickly, and the cppreference.com page is relatively short, which reflects the simplicity of compound literals. It helps that one can understand them as a local variable, local to the specific block that they are used in.
In contrast, C++ and Rust temporary lifetimes can vary, and those lifetime rules can confuse developers, like in https://fasterthanli.me/articles/a-rust-match-made-in-hell .
Mojo seems to avoid many of C++'s and Rust's issues on the topic about lifetimes.
Edit: The trade-off of C compound literals is as far as I can tell that their lifetime is longer than sometimes necessary.
For one reason, it is because C++ runtime (and its standard library) is a whole own can of worms which most people would rather not touch if they can afford to. Which they mostly can.
> Sure, C++ has its own downsides
"Sure, getting your eyes gouged out has its downsides, but is it better to read that awful mess of macros in C instead?" The answer most people would give to this question may surprise you.
Here we go again. Yes there are bad parts in the C++ standard library and there are good parts. But if you are just trying to do type safe generic data structures you are unlikely to touch the bad parts. Many codebases forbids parts of the standard library, e.g. LLVM forbids including <iostream>. You can forbid using parts of the standard library too.
> Yes there are bad parts in the C++ standard library and there are good parts.
Okay, other than <vector>, what are the good parts? Because as the sibling comments rightfully point out, migrating your codebase from C to C++ just to be able to use <vector> is not worth it.
The <map> is a sad joke played upon the C++ programmers by the standard committee.
Strings, something that C still doesn't do properly, not even having something like SDS into the standard library.
<map> does the work just fine, not everyone has winning microbenchmarks as part of their daily work.
Many of the big C++ projects I've worked with have custom string types since the standard one was defficient for some reason or another.
Exactly, and a simple usable string type is just a struct MyString { char *buf; size_t len; }; away. Actual magic is in how you use it, where you allocate it, how you integrate allocation and formatting and logging and I/O... i.e. all the things that aren't solved by crufty complex std::string either.
So simple, and yet most C projects never do it.
Plain C strings all over the place.
Since I learnt C in 1990, knowing to count up to 10 is enough, for the amount of times I saw it actually being done.
The projects and people I follow do this all the time. Just like putting a size field near each regular non sentinel terminated array is useful. But if not doing it (maybe linux kernel in many cases), no big deal either, don't sweat the small stuff. String slices are small and rarely perf critical.
And yet zillion ways better than C strings, which was the point.
> <map> does the work just fine
It has a rather weird interface, at least until C++ 17 when some of the deficiencies were patched somewhat.
It's a slow generic data structure with an unintuitive API. You can use it for leetcode or for CRUD. For anything more demanding it's horrifically bloated and bad. std::string too. Whenever you see STL datatypes like even string and map, you have to deal with RAII, implicit allocations, weird operator syntax, unexpected mutation (invalidation) and so on.
(Spporting or even encouraging destructive mutation, and by this I mean not incrementing counters or anything harmless but allowing iterator invalidations and crashes, are also why std::vector is bad in my opinion, these are idiomatic APIs for 90s and 2000s programming, which we should know better to avoid in 2026).
> For anything more demanding it's horrifically bloated and bad
C++ containers are designed for average demands. If you need something more specific, you can always use an alternative implementation. And it's better than messing with macros in pure C.
> you have to deal with RAII
What's problematic with it?
> implicit allocations
Allocations aren't implicit. It's usually clear from the documentation where allocation takes place (like in concatenating strings or copying strings).
> unexpected mutation (invalidation)
It's not the case with standard library containers. Mutating methods aren't const-qualified, so that it's clear where mutation can take place. And in C++ it's strictly recommended to mark as const everything in regular user code which shouldn't be mutated.
> C++ containers are designed for average demands. If you need something more specific, you can always use an alternative implementation.
As someone who has been programming exclusively in C/C++ for a long time -- the biggest selling point for these languages in 2026 is exactly being suited to doing something specific, not generic.
> Allocations aren't implicit
> in C++ it's strictly recommended to mark as const everything in regular user code which shouldn't be mutated.Theory and practice. Making everything const correct is too painful in practice, often impossible. It's a trap for bean counters that can't focus on getting some actual useful work done. I'm being harsh to my own past self here. Counter question: why include allocation mechanics with some existing data that never gets changed? Why should we have to add much more boilerplate to get the simpler thing?
> m[1] = 42; // implicit alloc
operator[] of associative containers is mutating and may allocate. It's mentioned in the documentation. And there is no operator[] overloading for const instances, so that you can't trigger an allocation by just reading elements from it.
> auto m2 = m; // implicit too
Taking a copy requires making an allocation. Do you expect some other behavior in such case?
> Making everything const correct is too painful in practice, often impossible
Maybe you are dealing with some legacy codebase (from 90s)? I have worked with multiple codebases in past 10 years or so and keeping things which shouldn't be mutated const wasn't a problem at all. All the code was written using such approach.
> why include allocation mechanics with some existing data that never gets changed
I don't think I fully understand this question. What never gets changed? In your example you are mutating a container and taking a copy of it (which can be changed later).
> Do you expect some other behavior in such case?
No, just saying this stuff is implicit and thus hard to read. More so the allocation on indexing assignment. and keeping things which shouldn't be mutated const wasn't a problem at all.
> and keeping things which shouldn't be mutated const wasn't a problem at all.
As soon as datastructures become more complicated and more interconnected, it's not clear anymore what const should even mean (issues are similar as with deep vs shallow copies, how do you even draw the lines, where are the objects?).
And the major philosophical flaw in the const vs. non-const distinction is that to make a strict separation you have to move everything mutable into constructor calls (for the most part, not getting more into the weeds of C++). Which is very awkward, it's a real tradeoff you need to be aware of. I realized only after playing these games for a long time what a waste of time it is and how much complexity it creates.
Great that setjmp/longjmp is explicit, and that in C there are even more liberties to cast away const than in C++, while some surprises in embedded, when the compiler decides const could have been placed into read only memory.
Placing data in .rodata (read only memory) is an actual useful application of const keyword. Not specific to embedded. Arguably there shouldn't have been multiple slightly different meanings of the keyword like that.
I don't know why you are now jumping to setjmp/longjmp, trying to make a point that somehow C is the worst programming languages ever, when all I am trying to argue is for sane programming practices, hinting that more complex features (line especially found in newer languages) are not solutions but part of the complexity problem.
> you have to deal with RAII
If you find that RAII is a problem, I pity how poor a programmer you must be...
You must be very experienced to be so judgemental! But maybe ask the many billions of voxels that get tested per second on my multithreaded and SIMD'ed cutting simulation.
C++ is the best language to write multi-architecture SIMD without relying on compiler magics like autovectorization. It gives you enough tools to define zero-cost abstractions to make SIMD nice.
Yeah... There are libraries like Google Highway but that seems to me like a bulky software abstraction layer even if it is a so-called "zero cost" abstraction. Maybe appropriate in some cases. In my case, I've implemented a couple of lines for AVX2 and AVX512, maybe around 100 lines for the most perf sensitive sections currently, not a big deal. The actual work is in the understanding of the problem and of the phyiscal hardware, and in the software architecture and data layout to even enable vectorized stream processing in the first place. I'm not concerned writing a couple of perf sensitive lines against 2-3 most important concrete vector ISAs. I also fancy adding a GPU backend later (requires D3D12/SM6.0 API level), Highway couldn't help with that.
RAII is terrible for memory resources - it's ok for things like locks I guess. Rarely do I want to couple initialization with allocation, I want bulk allocations/deallocations (and I want precise control over when that happens) and reset()-like functions so I can easily reuse memory.
It couples things and complicates things. Which creates friction against when refactoring a software architecture, making it harder to scale it up.
Fully agree, for locks or other simple begin/end pairs it doesn't create the same kind of architectural damage. But I don't use it even there, because RAII fundamentally doesn't play well with manual cleanup code. It's kind of an all-in game, if you use some RAII there are strong forces (whenever you need to get the "nesting" right) to convert all remaining manual begin/end type code to types that define that functionality out-of-line in the destructor/destructor, leading to fragmentation.
At least is there in the standard library, one doesn't need to invent one from scratch in every single project, or reach out to the tools floppy while not telling the employer due to code ownership.
No need to invent when you already know how it works.
I could re-type all the essential stuff from std::string that I've ever used myself within 10 minutes, no problem, without looking up external sources, including copy & move semantics and whatnot. But I'm deliberately not doing it. Because I don't like this "invention".
So what? You like <vector>, and make it the only allowed include. Write all other type safe generic data structures by hand using C++ syntax. Problem solved. In fact many old codebases migrated from C already has their own implementations of strings and vectors and hash tables, so these projects can totally forbid the C++ standard library versions in favor of their own versions, and only pull in <type_traits> for easier type safe generic data structure programming.
You cant touch C++ without bringing the object lifetime stuff in. And unlike strict aliasing, theres no flag to turn it off.
Object lifetime is the entire point of C++ and it solves ~100% of the emergent flaws in C programs.
I was just dealing with this: https://bugs.gentoo.org/show_bug.cgi?id=974323.
Also std::start_lifetime_at is a hack and ive seen nobody using it in all the placed where it aught to be used.
If optimizing based on object lifetimes could be turned off, itd be turned off everywhere for hardening like strict aliasing is.
In my personal opinion, the fix[1] for that issue clearly implicates C-style habits polluting a C++ code base. No right-thinking knower of C++ initializes objects with memset! Also I believe that -Wall would have flagged that, and I know for certain that cppcoreguidelines-init-variables + cppcoreguidelines-pro-type-member-init would have flagged it.
1: https://github.com/llvm/llvm-project/commit/905a88b923433eb8...
Its rather hard to introduce c++ into legacy c projects. You basically have to decide on a subset of features to use, and then you'll have to explain to the teams why the same looking code now takes 10x more compute to build.
Usually the way we do it here is we honor some interface then rewrite the subsystem in c++.
And then there's the real hurdle and that is getting the c++ idiom correct as it is very easy to just open the floodgates and let everyone write code that looks vastly different.
I'd rather not migrate my C codebase to C++ just to use an array container. Very hard to consistently limit the codebase to a strict subset of C++.
It is called a linter, more devs should learn to use a tool that was originally created for C in 1979.
The only decent linters I know of for C++ are clang-tidy and coverity and they are not good enough.
If the goal is language subsetting, they do the job just fine.
Can clang tidy restrict RAII entirely? Or any other linter?
If you want better tires on your car, why not just get a different car?
STL is amazing and the people that designed it were very smart.
Problem is C++ has many features which I likely won't be able to understand in this lifetime. But using C-style C++ is nuts.
Just the extra of STL is basically the C that C should have been. It's a shame not to have a string type or use brittle macros.
Not sure why author does it, but I use C over C++ for one reason: I'd rather not have random hidden malloc() scattered in my code. And no, it's not about latency or performance. Once my code takes an yet unexplored part and runs out of 200kB RAM, the will be no way for me to learn about it - running out of memory will bring down both the logger and the radio link, which is the only way to get the logs from a sensor installed twenty meters above ground in a hazardous environment facility. C may be unsafe, but most errors short of "writing to a random memory area" are either well-contained or at least reproducible. Dynamic memory allocation means that anything may crash everything. Manageable if you have a MMU and can contain crashes within isolated heap, but if not - I'd rather not bother. And yea, you can write zero-allocation C++ code, but why bother if most of STL is now unusable? And you get some new and exciting UB modes (seriously, no union aliasing, what the heck?)
Also, template metaprogramming is way more arcane than C macros. And I need compile-time metaprogramming in leu of dynamic allocation. So C macros it is for now (Zig is promising but still not there yet).
(C++) The worst programming language of all time https://www.youtube.com/watch?v=7fGB-hjc2Gc (10m ago)
These macro tricks (from the article) are not about recreating C++ in C. C is less opinionated (comp. to C++): it gives you fewer built-in abstractions; does not prescribe which DS dev. should use. It is bring-your-own-data-structures language. Bring whatever you choose. In C, newer language standard is not always better. Older lang standards support more platforms. There is a certain beauty in writing in an old language while still applying modern coding practices.
I like C. I don't hate other languages. I wouldn't use C for apps that should have been written in C# with WinForms...
Also see Templates in C by David Priver - https://www.davidpriver.com/ctemplates.html
He also has other interesting C techniques, namely;
Adding reflection to C - https://news.ycombinator.com/item?id=49964525
_Generic for Type Reification in C - https://www.davidpriver.com/creification.html
See also his C2y interpreter with REPL named "DrC" for the upcoming C29 standard (https://en.wikipedia.org/wiki/C29_(C_standard_revision)) - https://github.com/drpriver/drc
PS: I really like his style of writing and presentation; concise and precise without unnecessary fluff and page beautifying.
Hey that’s me! Cool to see people like my stuff.
You should write more ;-)
I also posted your "Adding Reflection to C" at https://news.ycombinator.com/item?id=49964525 and hope HN picks up on it and has a decent discussion.
You definitely should add a detailed post on your "DrC" compiler/interpreter; usecase, scope, techniques used etc. Since this is looking forward to C2y/C29 with some more extensions, i think people will enjoy playing with it in the REPL format.
I agree. Alas I have a day job and my other hobby is going for long hikes. But when the days get shorter and the weather is worse I’ll write some more!
I do wish to see comptime stuff in C some day. Or at a minimum your `defblock` implemented. I am so tired of having to escape new lines.
There is a proposal for #def / #enddef:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3531.txt
Oh great, the next C-hack C++ will have to adopt for compatibility...
Why do you think this is a hack? Also C++ does not have to adopt it. (but it probably would)
Lol at some point just implement a small compiler in C… reflection is kinda a hilarious thing to have like I understand the use case for generics, since it's not that that that hard to do with macros and quite commonly wished for
That `(1 ? (item) : (list)->payload)` was a neat trick. It gets optimized away, but the type comparison happens before that.
Still feels a bit like a party trick, but if it works...
It's somewhat of a forced trick nowadays, I think.
I actually thought from the title before I read the article that it was going to use _Generic, as in something like _Generic((item),__typeof__((list)->payload):...) .
You want attribute((overloadable)). Not _Generic. Noone wants _Generic, it should not have been proposed, nor specified, nor implemented.
Expressions that compile but never evaluate are bread and butter in C++ template metaprogramming.
Is it feasible to create a new language by adding features to C
just as was done with C++?
It's not worth it. The value of C is in compatibility, availability of compilers, and familiarity.
As soon as you change anything in a breaking way, start requiring your own compiler/transpiler, or introduce new idioms, you end up losing the things that keep C alive.
Users of C either like it exactly the way it is, or have to use a specific C version due to a vendor dependency or compliance.
An upgraded C not approved by the standards body gives you yet another niche language that is not C, but is still burdened with its old flaws.
Well said.
I really don't understand why people bring up other languages when one is discussing implementation of some "advanced/tricky/hackish/new" features in C. It is not as if the implementer does not know about the ease of availability in other languages but there is always some set of criteria which prevents switching to a new language.
On a related note, there is a dearth of written/learning material (books etc.) cataloging and explaining advanced architecture/design/implementation patterns in C though we know they exist in the tons of industrial-strength codebases out there.
There is also the fact that when you see an implementation in C of some feature from another language you better understand language design pragmatics eg. implementing inheritance and virtual functions in C gives you insight into how they work in C++/Java/C#/etc.
It would be nice to have something like C which was very much like C and Pascal (not the syntax) but which was basically C except no naked pointers by default etc, fewer footguns, but which would generate C.
mrustc generates (ugly) C from Rust. And doesn't borrow check or otherwise add any bounds checks. It only supports the parts of Rust that the Rust compiler itself needs, but that's quite a lot of it.
And Objective-C, yet somehow people reinvent them badly in C.
I am working on a language that was C with extensions, transpiled to plain C, but the C syntax is kinda not great to work with (stuff like needing type tables and unbounded lookahead). At the point you clean up the syntax, you're not really C with extensions anymore.
C3 might be it because C3 has full C ABI compatibility so unlike most modern C-like alternatives, it checks out.
I mean you dont need to make a "language" at all, you can just write a librar for all the stuff you need. This stuff is just syntactic sugar.
For example, when I worked on writing embedded software for autopilots, we had 2 files, common.so and common.h that contained essentially a super robust typing framework. The way it worked is that you defined types through the provided functions at the beginning of your code, and all of the definitions were stored and checked at runtime at the beginning before the main execution loop took effect. So basically taking what a more robust language compiler would do and just moving that processing to the start of execution.
I use something similar for my local llm setup at home, where i can have my agent basically write tools for itself and when the tool fails, the error code makes it pretty easy for the agent to fix.
Congrats, you (re-)invented Objective-C!
Sure. After all, gcl and ecl compile to C source.
There are already plenty of such languages, Zig among others.
zig doesn't "extend" C in the way that C++ does.
But C++ does not extend C as well.
i guess i should say "the way that C++ _did_", although i do want to say "you know what i mean" since they do still share quite a bit
C3?
Nope, they went their own way now, see recent blog posts.
Related. Others?
I write type-safe generic data structures in C - https://news.ycombinator.com/item?id=44425461 - June 2025 (182 comments)
Type-safe generic data structures in C - https://news.ycombinator.com/item?id=26735655 - April 2021 (52 comments)
As far as I know many C programmers think the addition of variable length arrays in C99 was a mistake. What would be the downside of this approach?
VLAs are anti C. I also dont even think _Generics should be in the complier. The complier should do minimal processing of syntax in terms of decision making, with only focus on being optimizing code.
Because in the flip side, you get C++ templates, which are turing complete, so you can write entire program syntax that the compliler executies during the complie process.
So much so, that it was made optional annex in C11, while Google paid to remove all their use from the Linux kernel.
I do not get the connection with a VLA in this context, but if you need a VLA, by all means use it. It is basically always better than the alternative.
> I do not get the connection with a VLA in this context
The article uses a struct with a VLA as the last element.
I see. This array of unknown length at the end of a struct is called a flexible array member and not a variable length array (although it also refers to an array of variable length it is a different language feature).
Yes, and variable length arrays were made an optional part of the standard in C11. Whereas flexible array members remain a standard required feature.
Flexible array members don’t allocate a dynamic amount of memory on the stack.
VLAs are supported by basically all modern C compilers though, and I do not think adding them was a mistake (I certainly use them a lot!). They got a bad reputation due to stack clash attacks, but in the past some compilers did not implement stack probing (clang was very late). But this was fixed a decade ago.
Their specification is pretty bad, allowing code like:
`typedef`s with side effects...True, I would also prefer side effects would not be allowed. But simply don't do this. This is not a reason to avoid the feature in general.
What happens when I put a variable of a struct type that contains a flexible array member on the stack?
The array has size 0. In GNU C, you can initialize it and then it has a fixed size corresponding to the initializer.
I just want C with classes, like C++ started out as.
What I'd really like is a standards-conformant (C++98/03) compiler that actually enforces the standard properly (or maybe it becomes a new standard), and ONLY allows that version to be used, AND only the classes.
No templates, no exceptions, no standard library (just use a plain libc).
Have you tried Objective-C? It’s Smalltalk-style OOP meets C. It’s also a strict superset of C, unlike C++.
Yes, unfortunately compilers for embedded platforms are often hard to come by.
I absolutely cannot remember the details, but we did typesafe, macro based generic data structures in C in an undergrad class I took ~20 years ago (CMU Operating Systems). The idea has definitely been around, though I don't know if the implantation was the same.
While C++ template is using value types, C generic pointer is not.
See also BSD queue.h: https://man.openbsd.org/queue.3
https://github.com/openbsd/src/blob/master/sys/sys/queue.h
Jesus, I hate those macro hacks so much. Most of the time you only need a single container, so writing an ad-hoc implementation is cleaner than that.
The extent some will go to avoid touching C++.
Indeed. After having suffered from C++ a lot, I am also really avoid touching it if I can.
But if you compare some C++ template container to a C macro solution, I also do not find the macro solution to be more complex.
I would not expect any other kind of answer.
We will keep on agreeing to disagree.
The difference between me and you is that I do not usually post under C++ articles something negative about C++. Instead I respect that people interested in C++ may have their own reasons. For some reason you find it appropriate to post something negative under each C article.
I could tolerate it if it were at least some interesting criticism,.
Because I find a waste of time to insist in pushing C, with all its flaws, into the industry.
Microsoft, Google, Apple and co have done the right decision regarding to what extent C is still required on their platforms, when we have Typescript for C for about 40 years.
Now if WG14 was actually doing type safe enumerations, sorting out implicit conversations and arrays decaying into pointers only to save typing 4 additionally characters per location, catching up to PL/I strings and arrays, I might be a bit more positive.
One can wait for WG14 to ever deliver that, assuming it will ever happen, or take the easier way out, and use such features on C++ today.
In reality, we as industry should have long replaced both of them with something better, since Ada and Modula-2 came to be, but alas the industry always takes the easier path, like mountain rivers.
Yes, but please take your general grievances about than Pascal / Modula / Ada did not win elsewhere than to every discussion related to C. Maybe write a nice Modula program and make submission aoub this?
Well, all C authors did just that, they moved on from their creation, trying a first successor with Alef, Limbo and then Go.
Likewise by 2002, AT&T also decided C had enough of lifetime and started the Cyclone project, which has a great effect in modern type systems.
They might have not won over C, others will, with projects whose influences trace back to where UNIX and C were born, quite ironically.
Which is much more interesting to post about than Modula-2 in 2026.
[flagged]
I've tried doing this for a few years and it just sucks ass. Just use c++ and templates if you need proper generic data structures. C is a defective language.
I start to like my experimental macro containers: https://codeberg.org/uecker/noplate/
Examples: https://godbolt.org/z/hecqs78xs https://godbolt.org/z/YnrcjKrEn
Not perfect, but also not really inferior to C++ in my opinion.
Can't be all that defective if it underpins most of the technology in the world
It absolutely can. See for example: lead.
Care to elaborate more ? is it suck because it's toxic to human ?
Most elements on periodic table is toxic to human.
Problems with lead: it's toxic and it accumulates, lead doesn't leave you and builds up over time. It's not just toxic in the sense that too much will kill you, but even small quantities can cause nerve and brain damage, among other things. It is easier for your body to absorb lead than many other elements.
My comment was pointing out that despite lead being known for millennia as a problem in people, it was used for:
* water delivery pipes * plates and cutlery and cups * a paint ingredient in everyone's home * a sealant * a fuel additive that was spewed into the air by every motor vehical * a lubricant in a lot of machinery * a common additive to many additional products all over the place * a common additive in industrial processes leaving lead residue on products that wouldn't otherwise contain lead.
So the phrase: "underpins most of the technology in the world" somewhat realistically applies to lead - in the early 1900s it was everywhere all the time.
And as i pointed out at the start of this - it is kind of a bad choice to be using all the time in everything since it causes so many problems for people. Humanity has been dramatically reducing the use of lead in everything for a long time now (decades) and will continue to do so for a long time. The bad effects of all the lead use during the industrialization of our species will remain for quite a while.
So my whole point was: just because something was used in the creation of great outcomes, it doesn't make it any good in a fundamental way. I'm saying C is like lead in my analogy.
We really should lock up the inventor of lead.
When has that ever stopped a shit language? Just let it die already.
Never gonna happen. As soon as you kill it off, someone's going to realize they need a very minimal fast "unsafe" language for something, and reinvent C, probably poorly
I think it is a pretty good language. Simple, elegant, performant, stable, and fun to write. Most programs I like for being efficient, non-bloated and reliable turn out to be written in C.
Or, in 2026, Rust (or Zig, I don't care).