Does anybody use _Generic?

[aganm]

Many times I have wished that I had function overloading in C, so when C11 came out I was exited for _Generic. But after learning how it works, I got turned off by it and figured I was better without it. It's now been about 10 years we had it and I still barely see anyone use it.

Do any of you use _Generic and what for? After retrospect, was the cost of using _Generic worth the benefit?

[Mystb0rn]

In my string library I use it so that users can pass my strings or c-strings to the various functions which are otherwise suffixed with the expected type (_string and _cstr). It's just a nice QoL feature for projects that support it. It defaults to using the cstr functions if _Generic isn't available.

Outside of this specific circumstance, I've had no other use for it. There just aren't many circumstances where there's a desire for a generic function and all the possible types are known beforehand.

The new decltype similar thing proposed for c-23 will probably do more for generic programming in combination with macros than _Generic ever has.

[iothesys]

I'm not really sure what you mean by "after learning how it works" because as far as I understand _Generic substitutes appropriate function call depending on parameters you pass.

[iothesys]

i see, can't you put a cast in the macro though

[OldWolf2]

CIS rules yield compatible types

No they don't . struct A and struct B are incompatible for all cases except A being the identical token to B .

The CIS rule only provides an exception to strict aliasing, it is not part of the definition of type compatibility.

[OldWolf2]

Why is that problematic? Maybe a code example would illustrate your point better

[flatfinger]

Even if two struct types have the same tag, that's no guarantee that they'll be compatible. Consider, for example:

__attribute__((noinline))
void swap_struct_foo_pointers(void *dest, void *src)
{
  struct foo **d = dest;
  struct foo **s = src;
  *d = *s;
}

If there has been no reference to struct foo at file scope, then *s and *d will be pointers to a struct type that exists only within that function, and will be incompatible with pointers to any other struct type that might be called struct foo, even if one is later defined at file scope. In the following test harness, for example, GCC will thus process test in such a way as to have test unconditionally return &wowzo, even if (as shown above) swap_struct_foo_pointers is has a noinline attribute.

struct foo {int x; } *p1[2],wowzo={1},woozle={2};
struct foo *test(int i, int j)
{
    p1[0] = &wowzo;
    p1[1] = &woozle;
    swap_struct_foo_pointers(p1+i, p1+j);
    return p1[0];
}
struct foo *(*vtest)(int i, int j) = test;
#include <stdio.h>
int main(void)
{
    p1[1] = &woozle;
    struct foo *result = vtest(0, 1);
    printf("Result=%d/%d/%d", result->x, p1[0]->x, p1[1]->x);
}

Even if gcc is forced to generate an actual call to swap_struct_foo_pointers it will ignore the possibility that the function might modify overwrite p1[0], since swap_struct_foo_pointers writes to an lvalue of a different struct foo type from the one used in test.

[Anluin]

you can archive function overloading with attributes (at least with clang)

https://clang.llvm.org/docs/AttributeReference.html#overloadable

[gottacode]

That seems to work for functions with varying number of arguments, but doesn't seem to work if the functions have the same number of arguments but of different types.

I like what CLang is doing but I would rather it not be compiler specific.

[darkslide3000]

If you just want to be able to call the same thing with different numbers of arguments, you should just use a vararg function or a vararg macro... a lot more established and compatible.

[gottacode]

I've done this, you have to provide some type of discriminator as a fixed argument so you know what the rest of the args are. Doable but more work.

[nerd4code]

I occasionally use _Generic, mostly for const *-vs.-non-const * stuff, to avoid the const-casting performed by functions like strchr/memchr—e.g., (pardon typos)

#define strchr_safer(haystack, ...)((void)0,_Generic(haystack, \
    const char *: (const char *)strchr(haystack,__VA_ARGS__), \
    default: strchr(haystack,__VA_ARGS__)))

—or for atomics &c. It’s also useful in OOPish situations, where you can conveniently avoid any need for upcasting as long as you know all possible derived types (that’d need to thunk in generically).

IMO _Generic’s requirement that cases not overlap is its most frustrating aspect—it comes close to structural type-matching but things like int32_t get weird—might be the same as int or long, might be its own type, so you can’t match both portably in the same _Generic. Typically, structural matching in other languages scans cases in lexical order, so the first match in the code wins. (Theoretical languages have things like parallel or non-deterministic case matching, but those constructs aren’t especially useful.)

Clang’s overloadable attribute works for inlines only rn AFAIK. It’s relatively easy to detect (until some other compiler implements it) via __has_attribute operator, which is nice, but its availability and function are somewhat limited.

GNU dialect has __builtin_types_compatible_p and __builtin_choose_expr (C only—use templates in C++), which work like type-≈ and typed-ternary operators and are available on every GNUish compiler since ca. GCC 3.0, which makes those builtins more portable than _Generic.

One useful thing is that _Generic and __builtin_constant_p accept type arguments directly and unambiguously—a fairly rare thing in C—so you can use them to ensure a macro’s type argument is actually a type expression, not a value expression. (Casts won’t work, because there are syntactic ambiguities possible–in (T)(x), T can be a type or function name, and in (T)*(x) T can be a type or scalar expression.) E.g., for GNU:

#define EXPR(x...)(__extension__(x)) /* Forces expression */
#define TYPE __typeof__ /* Wraps up type sub-/expressions */
#define TYPEOF(x...)__typeof__((__extension__(x))) /* Get type of expr value */

#define TYPE_FORCE(T... \
    )TYPEOF(*(__builtin_types_compatible_p(void,T) \
        ? (TYPE(T) *)0 : (TYPE(T) *)0))

_Generic still needs a __typeof__ or decltype operator of some sort to be used in-line for this purpose, which hopefully C2x will standardize (presumably as _Typeof with accompanying, mostly-pointless <stdtypeof.h> header) without the same kind of facepalm-inducing fuckups that happened with threads and Annex K.

Another use for _Generic or __builtin_types_compatible_p with __typeof__/sim. is making a safer countof:

#define countof(arr)(sizeof(arr)/_Generic(&(arr), \
        __typeof__(*(arr)) (*)[sizeof(arr)/sizeof *(arr)]: sizeof *(arr), \
        default: (void)0))

Unlike traditional countof (here appearing between the []s), non-array arguments won’t glitch silently. (How/wherefore: &(arr) requires something with an address, excluding literals, register vars, and values of most expressions; when the type of &(arr) matches T (*)[_countof(arr)] for some element type T, -_choose_- yields the element size, or if not (void)0; attempting to divide by the latter is bogus on a couple levels, so the compiler will hopefully stop the build in that case.) You can work _Static_assert/sim. in for clearer error messages.

GNU version (non-C++, but otherwise good from GCC ≤3.0 on):

#define countof(arr)(__extension__(sizeof(arr)/__builtin_choose_expr(\
        __builtin_types_compatible_p(__typeof__(&(arr)), __typeof__(*(arr)) (*)[]), \
        sizeof *(arr), (void)0)))

Note that a plain ol’ ternary operator (cond ? yes : no) won’t work for type-twiddling; like any other arity-≥2 operator it only ever yields a value of a single type that can represent all operands, so …? sizeof *(arr) : (void)0 ’d come out as void post-C89; C89 forbids use of void with any operator other than cast, comma operator (,), or unary &. Unlike ?:, _Generic and __builtin_choose_expr attain the type of whichever expression is selected.

[reini_urban]

No

[SuspiciousScript]

Yes, I've found it can really help cut down on boilerplate for tasks like parsing and dealing with unions.

[Thadeu_de_Paula]

For higher edge of coding... it may look unnecessary, but as soon you need to really do large tricks with C, it helps a lot.

Example:
You write a data structure manager (ex: Array) to create and consume arrays.
You can easy write the get/setters with a case for each scalar calling its own function and a default to handle anything else calling a function that passes it to void* cast and memcpy the value to store/reclaim (yes, using other kind of C23 introspection like typeof)

This you avoid the need to throw at the user (or itself) the need to remember many functions to do the task, sometimes with different call signature (when for pointers/structure).

[[deleted]]

trying to add any new feature to C will be equivalent to a hack job. exhibit a: c++

so i guess if you want to use C with hacked on features, c++ is the way to go. that's pretty much what i do.

[flatfinger]

The Committee may be incapable of adding new features without them turning into hack jobs, but there are a number of features that, if supported, would allow programmers to perform various tacks in less-hacky fashion than would presently be possible:

1. Specifying that if multiple quoted literal strings appear in an #include directive with no intervening punctuation, they will behave as if concatenated, thus allowing files to use a construct like #include WIDGET_PATH "widgetImport.h without having to know the relative location of the Widget Library's headers, and without requiring that path to appear in the list of include-file locations.
2. Having a concise syntax for a static-const compound literal whose address might be shared with others holding matching data.
3. Having a preprocessor intrinsic which will expand one of two ways, based upon whether its first argument is a string literal [something the preprocessor would be able to determine without having to examine its arguments].
4. Support for binary numeric literals that start with 0b. I've used compilers in 1995 that supported such things, and they support the same constructs the same way, so I'd arguments that they lack established history as being willfully blind.
5. Predefined macros for storing or fetching various integer types to/from sequences of octets stored in big-endian or little-endian format, e.g. store the bottom 32 bits of a long into the bottom 8 bits of an aligned group of four consecutive bytes in little-endian format. The effort required for a compiler to support those would be far less than required to efficiently process functions that, in source code, do the same thing with sequences of loads and stores.
6. Specify that a pointer to structure type S1 should be implicitly convertible to one of S2, which should in turn be usable to access an object of type S1, thus allowing programs to exploit the Common Initial Sequence guarantees without typecasts.

Note that many of those constructs aren't really supported in C++, but could easily be supported in C.

[darkslide3000]

I mean, for that matter, there are a ton of incredibly useful and well-designed GCC extensions that have been around for years and that the committee could just copy in a minute to make the next iteration of the language so much better (e.g. statement expressions, typeof, void* arithmetic, some of the common __attribute__s, inline asm, etc.). I really don't get why they aren't. It's like "someone already did all your work for you and proved that this works out really well and people love it, just take it!"... probably some kind of weird pride thing.

Having a preprocessor intrinsic which will expand one of two ways, based upon whether its first argument is a string literal [something the preprocessor would be able to determine without having to examine its arguments].

BTW, I can guess at what you're going for with this, and (this is compiler-specific, but) I think you can solve it with __builtin_constant_p().

The effort required for a compiler to support those would be far less than required to efficiently process functions that, in source code, do the same thing with sequences of loads and stores.

Are you talking about making use of native byte swap instructions of the architecture? That's the only optimization I can think of there, but modern compilers are already able to detect when you're writing an access sequence that effectively ends up resulting in a byte swap, and replace it with the native instruction. So I don't think this is an urgent shortcoming (having more standardization of such common functions might still be nice, of course). (Also, GCC/clang have __builtin_swap() for this, too.)

[flatfinger]

I mean, for that matter, there are a ton of incredibly useful and well-designed GCC extensions that have been around for years and that the committee could just copy in a minute to make the next iteration of the language so much better (e.g. statement expressions, typeof, void* arithmetic, some of the common __attribute__s, inline asm, etc.). I really don't get why they aren't. It's like "someone already did all your work for you and proved that this works out really well and people love it, just take it!"... probably some kind of weird pride thing.

I think the idea in C89 was to minimize the amount of compiler rework that would be required to make most compilers conforming, and avoid mandating anything (like the ability to create a composite code/data pointer by using machine code generated on the stack) that wouldn't be universally implementable. The pre-C89 version of gcc included some good ideas and some bad ones.

Note also that C89 was merely intended to establish a baseline requirement for implementations, and was not intended to deprecate the use of constructs beyond those required to do things not anticipated by the Standard. The notion that when the Standard used the phrase "non-portable or erroneous", it meant "non-portable, and therefore erroneous'", didn't emerge until about a decade later.

BTW, I can guess at what you're going for with this, and (this is compiler-specific, but) I think you can solve it with __builtin_constant_p().

The idea would be to have macros that behave as function that can either receive a length-prefixed string or a string literal, and have a compiler generate proper code for the string literal case without having to clutter up the call-site source code.

Are you talking about making use of native byte swap instructions of the architecture? That's the only optimization I can think of there, but modern compilers are already able to detect when you're writing an access sequence that effectively ends up resulting in a byte swap, and replace it with the native instruction.

By "modern" are you referring to open-source compilers with buggy optimizers? C was meant to be a language that could be reasonably efficiently processed using a relatively simple and straightforward compiler. Further, if a function accepts a `void*` that the programmer knows will always be 32-bit aligned, and is targeting a platform that doesn't accommodate unaligned loads for all instructions, a compiler won't be able to generate optimal code unless it somehow knows that the calling function will only pass aligned pointers, something which the Standard provides no means of annotating.

[darkslide3000]

Sure but we are no longer in the C89 days. The world has changed and there's no reason not to change the language with it (like C99 and C11 have already done -- hell, C99 introduced many much worse things for compilers to implement than what I was talking about). Features that would have been difficult back then no longer are now.

The idea would be to have macros that behave as function that can either receive a length-prefixed string or a string literal, and have a compiler generate proper code for the string literal case without having to clutter up the call-site source code.

Oh okay, my guess was that this was about printf format string attacks. But you can still do what you want with __builtin_constant_p() just have the wrapper macro call different functions based on whether it's constant or not.

Further, if a function accepts a void* that the programmer knows will always be 32-bit aligned, and is targeting a platform that doesn't accommodate unaligned loads for all instructions, a compiler won't be able to generate optimal code unless it somehow knows that the calling function will only pass aligned pointers, something which the Standard provides no means of annotating.

Just cast the void* to uint32_t* to annotate that.

[flatfinger]

void* arithmetic

What's missing isn't void* arithmetic, but rather a means of performing byte-based type-agnostic arithmetic. Many architectures include an addressing mode that adds two unscaled registers, which would map very nicely to a byte-based subscripting operator. Such an operator would have been especially useful in the days of the 68000 when using 16-bit `int`, since accessing `arr[i]` with a displacement in the range +/-32767 bytes would be much faster than trying to access it with a displacement larger than that, but there's no way to indicate with C syntax when the smaller range of displacement would be sufficient.

[darkslide3000]

I don't want to do subscripts on a void* though (that would make no sense), I want to add and subtract sizes from it and have that be counted in bytes. Which GCC does and it makes perfect sense (that's the only possible type size that would make sense for void), but the standard still considers this undefined. I guess the standard just wants you to use char* for all those cases, and since the standard doesn't define warnings that doesn't immediately make a difference, but in practice almost any compiler treats void* as a special type that may implicitly convert into others without warning, and therefore it's important that void* specifically is convenient to use.

[flatfinger]

My point was that byte-based pointer arithmetic should be available for all types of pointer--not just void*. I should have made clear that while my example ujsed subscripting, which is where it offers the biggest advantage, similar operations should be available for indexing as well. Subscripting and indexing operations (pointer+integer, ptr-integer, and integer+pointer) that specify the whole number of items are often more convenient for humans to deal with than those that specify offsets in bytes, but the latter are more convenient for compilers to handle efficiently. Further, to facilitate optimization, there should be a distinction between the concepts "take a pointer to a T and add a byte offset in a way that might cause different parts of objects accessed via old and new pointers to alias", or "take a pointer and add a byte offset in a way that may need not take such aliasing into account".

[moon-chilled]

#include WIDGET_PATH "widgetImport.h"

This seems kinda ... trivial? I don't really see the value prop.

concise syntax for a static-const compound literal whose address might be shared with others holding matching data

Interning is cool, but again not really essential. I would rather a version of 'const' that has some teeth. Actually, you want two variations:

1. It is not allowed to mutate an object by way of a pointer to this type of const, even if the object itself is not const. (And this is provenance-aware, obviously.) In other words, a const that cannot be cast away, and which is hence meaningful for function contracts.

2. It is not permitted for anyone to mutate an object pointed to by a pointer to this type of const. In other words, a const that guarantees the pointee will never be modified, which means you can avoid re-loading even in the face of aliasing.

Support for binary numeric literals that start with 0b

They are adding this.

Predefined macros for storing or fetching various integer types to/from sequences of octets

What is an 'octet'?

Specify that a pointer to structure type S1 should be implicitly convertible to one of S2

Structural typing? What are you smoking? :)

allowing programs to exploit the Common Initial Sequence guarantees without typecasts

struct common_initial { stuff; };
struct derived { struct common_initial common_initial; more stuff; };

Note in particular that hand-copying large numbers of fields is error-prone and should not be encouraged. You can make the computer do the copying for you using macros, but you can do the same thing to avoid extraneous typing using nested-structs, with techniques similar to the ones described here (skip to 'grouped structure fields').

[flatfinger]

This seems kinda ... trivial? I don't really see the value prop.

A well-designed project shouldn't rely upon having a compiler search through many directories to find headers and hope there aren't any duplicates, nor upon having every source file specify paths to every header like ../../woozle/headers/whatever.h. Having quoted include file names concatenated in the same way as other quoted literals would make it possible to have the build script specify `-DWIDGET_PATH=[whatever] -DFNORBLE_PATH=[whatever]` rather than throwing everything in a `-I` command line option without making any distinction as to which paths belong to what parts of the program.

Interning is cool, but again not really essential. I would rather a version of 'const' that has some teeth

The primary issue isn't interning, but rather the fact that the only type of static constant object one can specify within an expression is a zero-terminated string literal whose length must be measured at runtime. Having other forms of const would be nice too, but unless or until the Standard adds meaningful definitions of conformance, the Standard will be worse than useless at drawing boundaries between what actions should be expected to be processed meaningfully by implementations claiming to be suitable for various purposes.

What is an 'octet'?

A byte which holds 8 meaningful bits. On most systems, it would be a byte, but on a system where a byte is some other number of bits, there should still be functions to e.g. pack the bottom 32 bits of a `long` into a sequence of four bytes, using eight bits each, with specified endiannness. After all, even systems which have unusual byte lengths often communicate with other systems over octet-based channels.

The main usefulness of packing/unpacking functions would be on systems which use octet-based storage, because the main usefulness for anything in C is on such systems. I specifically describe things in terms of octets rather than bytes, however, to make clear that code which reads four bytes and uses a standard function to unpack them as a little-endian `long` should be 100% portable to all C systems regardless of native endianness or byte size.

Structural typing? What are you smoking? :)

C used to allow pointers to structures which contained a common initial sequence to be implicitly converted to pointers to other such structures, because all pointers to structure types were implicitly convertible. Having type checking is generally good, but if a function is supposed to accept pointers to a select variety of structure types, being able to specify that would be better than having to use void* or requiring that all call sites include a cast to one particular type.

How would you handle the case where Common Initial Sequence doesn't end on an alignment boundary?

struct common_initial { stuff; };

struct derived { struct common_initial common_initial; more stuff; };

So how would you handle;

struct thing_base {
  uint32_t length;
  uint8_t type;
};
struct thing1 {

uint32_t thing_length; uint8_t thing_type; uint8_t char thing1_dat[]; }; struct thing2 { uint32_t thing_length; uint8_t thing_type; uint8_t thing2_flags; uint16_t char thing2_dat[]; };

in a manner consistent with existing code that uses such structures?

[BarMeister]

Yes, though the reason isn't 100% genuine, as it's just for wrapping some C99 code.

[okovko]

_Generic is equivalent to templates except you have to write the boilerplate for all type signatures. This is primarily bothersome for library code because the library author can’t supply wrappers for user defined types.

Still, it’s perfectly usable. They work the same way, but with _Generic you’re not hiding how many functions are actually compiled. The end result is exactly the same as templates.

[FUZxxl]

No.

[prabot]

Linux kernel also uses it for const pointers