[sirwhinesalot]

The most insulting thing about _Generic is the name. Really? _Generic? For a type-based switch with horrific syntax? What were they thinking...

That said, generic programming in C isn't that bad, just very annoying.

To me the best approach is to write the code for a concrete type (like Vec_int), make sure everything is working, and then do the following:

A macro Vec(T) sets up the struct. It can then be wrapped in a typedef like typedef Vec(int) Vec_i;

For each function, like vec_append(...), copy the body into a macro VEC_APPEND(...).

Then for each relevant type T: copy paste all the function declarations, then do a manual find/replace to give them some suffix and fill in the body with a call to the macro (to avoid any issues with expressions being executed multiple times in a macro body).

Is it annoying? Definitely. Is it unmanageable? Not really. Some people don't even bother with this last bit and just use the macros to inline the code everywhere.

Some macros can delegate to void*-based helpers to minimize the bloating.

EDIT: I almost dread to suggest this but CMake's configure_file command works great to implement generic files...

[uecker]

There are less annoying ways to implement this in C. There are at least two different common approaches which avoid having macro code for the generic functions:

The first is to put this into an include file

  #define type_argument int
  #include <vector.h>

Then inside vector.h the code looks like regular C code, except where you insert the argument.

  foo_ ## type_argument ( ... )

The other is to write generic code using void pointers or container_of as regular functions, and only have one-line macros as type safe wrappers around it. The optimizer will be able to specialize it, and it avoids compile-time explosion of code during monomorphization,

I do not think that templates are less annoying in practice. My experience with templates is rather poor.

[sparkie]

An idea I had was to implement a FUSE filesystem for includes, so instead of the separate `#define type_argument` (and `#undef type_argument` that would need to follow the #include), we could stick the type argument in the included filename.

   #include <vector.h(int32_t)>
   #include <vector.h(int64_t)>

The written `vector.h(type_argument)` file could just be a regular C header or an m4 file which has `type_argument` in its template. When requesting `vector.h(int32_t)` the FUSE filesystem would effectively give the output of calling `gcc -E` or `m4` on the template file as the content of the file being requested.

Eg, if `vector.h(type_argument)` was an m4 file containing:

    `#ifndef VECTOR_'type_argument`_INCLUDED'
    `#define VECTOR_'type_argument`_INCLUDED'

    typedef struct `vector_'type_argument {
        size_t length;
        type_argument values[];
    } `vector_'type_argument;
 
    ...
    #endif

Then `m4 -D type_argument=int32_t vector.h(type_argument)` gives the output:

    #ifndef VECTOR_int32_t_INCLUDED
    #define VECTOR_int32_t_INCLUDED
    
    typedef struct vector_int32_t {
        size_t length;
        int32_t values[];
    } vector_int32_t;
    
    ...
    #endif

But the idea is to make it transparent so that existing tools just see the pre-processed file and don't need to call `m4` manually. We would need to mount each include directory that uses this approach using said filesystem. This shouldn't require changing a project's structure as we could use the existing `include/` or `src/` directory as input when mounting, and just pick some new directory name such as `cfuse/include` or `cfuse/src`, and mount a new directory `cfuse` in the project's root directory. The change we'd need to make is in any Makefiles or other parts of the build, where instead of `gcc -Iinclude` we'd have `gcc -Icfuse/include`. Any non-templated headers in `include/` would just appear as live copies in cfuse/include/, so in theory this could work without causing anything to break.

[sirwhinesalot]

That's the craziest idea on this topic I've seen so far! I'm not sure that's a good or a bad thing, but it sure is a thing!

[sirwhinesalot]

Those techniques being less annoying is highly debatable ;). Working with void* is annoying, header includes look quite ugly with the ## concatenation everywhere or even a wrapper macro. It also gets much worse when you need to customize the suffix (because type_argument is char* or whatever).

Sometimes the best option is an external script to instantiate a template file.

[uecker]

It may be debatable, but I would say C++'s template syntax is not nicer. I do not think working with void pointers is annoying, but I also prefer the container_of approach. The ## certainly has the limitation that you need to name things first, but I do not think this much of a downside.

BTW, here is some generic code in C using a variadic type. I think this quite nice. https://godbolt.org/z/jxz6Y6f9x

Running a program for meta programming are always a possibility, and I would agree that sometimes the best solution.

[1718627440]

I don't think

    T ## _foo (T foo, ...)

is that much different from

    <T>::foo (T foo, ...)

Same for:

    foo (Object * a)

vs:

    foo (void * a)

[cyber1]

Hey, I understand you and know this stuff well, having worked with it for many years as a C dev. To be honest, this isn't how things should generally be done. Macros were invented for very simple problems. Yes, we can abuse them as much as possible (for example, in C++, we discovered SFINAE, which is an ugly, unreadable technique that wasn't part of the programming language designer's intent but rather like a joke that people started abusing), but is it worth it?

[SAI_Peregrinus]

The name has to be ugly, new names in C are always taken from the set of reserved identifiers: those starting with an underscore & a capital letter, or with two underscores. Since they didn't reserve any "normal" names, all new keywords will be stuff like `_Keyword` or `__keyword`, unless they break backwards compatibility. And they really hate breaking backwards compatibility, so that's quite unlikely.

[sirwhinesalot]

The problem is not the _G, the problem is the "generic". It is a completely wrong name for what it does.

[uecker]

This is an old tradition in ISO C. unsigned actually means modulo and const actually means immutable.

[ioasuncvinvaer]

username checks out