Type Safe Generic Data Structures in C (2025) (danielchasehooper.com)

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.

    std::map<int,int> m;
    m[1] = 42; // implicit alloc
    auto m2 = m; // implicit too

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

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.

  $ 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]

  $ 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]

If you want better tires on your car, why not just get a different car?

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

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.

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.

Expressions that compile but never evaluate are bread and butter in C++ template metaprogramming.

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

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.

    #include <stdio.h>
    #include <stddef.h>
    void v(int y[printf("hello world!\n")]){ 
    }

    int main(){
        v(NULL);
        typedef int wut[printf("oh no\n")];
    }
    $ cc vla.c && ./a.out
    hello world!
    oh no

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.

And Objective-C, yet somehow people reinvent them badly in C.

There are already plenty of such languages, Zig among others.

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.

C3 might be it because C3 has full C ABI compatibility so unlike most modern C-like alternatives, it checks out.

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.

Sure. After all, gcl and ecl compile to C source.

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.

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

Hey that’s me! Cool to see people like my stuff.

The extent some will go to avoid touching C++.

Or, in 2026, Rust (or Zig, I don't care).

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