Hacker News Reader

Comment by flohofwoe | Hacker News Reader

True, but I also consider interesting combinations of standard features, especially C99+ features useful "tricks", because C99 features which make life so much easier are usually little known in predominantly C++ circles, because C++ only supports an outdated and non-standard subset of C.

E.g. this is 'named, optional arguments East Egg' is a useful trick which also improves readability:

    my_func((my_struct) { .bla = 1, .blub = 2, });

View on HN

I've tried something similar previously.

    typedef struct pixel {
        int r;
        int g;
        int b;
    } pixel_t;

    #define PIXEL(red, green, blue) \
    (pixel_t)                       \
    {                               \
      .r = (red),                   \
      .g = (green),                 \
      .b = (blue)
    }

Then I could invoke the function

    void display_pixel(pixel_t pixel);

by calling,

    display_pixel(PIXEL(255, 255, 255));

And you could even,

    return PIXEL(255, 255, 255);

Like magic. In other words, how do you pretend that you have syntax-level OOP in C... On retrospect, the macro could reduce readability, writing the argument explicitly may be better.

    display_pixel((pixel_t) {.r = 255, .g = 255, .b = 255});

I would recommend not doing that. Just use the initializer syntax, or write an inline function.

C++ supports C features to the extent that they don't overlap with C++ ones.

The compatibility with the C library is up to C11 for example.

I think what GP is referring to is C++ not supporting C's designated initializers, restrict qualifiers, or flexible array members features. These are roughly the only C features not in C++ that are worth supporting (the STL in C++ works better than VLAs, and templates work better than type-generic macros). All of the other new C features are either backported C++ features with different spellings, or new functionality (mostly library) that C++ adopts.

VLAs are gone, were made optional in C11, thus every compiler that jumped from C89 to C11 never bothered with them.

Google even sponsored a massive effort to clean the Linux kernel of their use.

A subset of designated initializers is supported in C++20.

> A subset of designated initializers is supported in C++20.

Took them only 21 years... And this standard being so recent, most projects won't have that for years to come.

Doesn't matter, the point was what C subset does C++ support today.

https://godbolt.org/z/GW59rM

C++20 designated initializers must be specified in definition order, whereas they don't in C99.

In your example,

    Point point = {.z = 2.0, .x = 1.0};

produces a compilation error. This is annoying, but workable. And at least it's a compile-time error, rather than a bug that perniciously sneaks into production.

Why do you think I wrote "A subset of designated initializers is supported in C++20."?

There's a surprising amount of perfectly valid C code that's not valid C++ (not even taking regrettable design warts like VLAs into account). The "common subset" of C and C++ is both a subset of C, and a subset of C++, e.g. C++ has forked C and turned its C subset into a non-standard dialect.

It's interesting that the other C descendant Objective-C has decided to "respect" its C subset instead of messing with it, with the result that new C standards are automatically supported in ObjC.

A descendant that would be dead by now wouldn't Apple decided to buy NeXT.

VLAs are dead, a broken design fixed in C11 by removing it from the standard, no idea why everyone keeps referring to them.

The one good use of VLAs I know of is casting a buffer into a multidimensional (variable-length) array to allow for subscripting to work.

Whatever good uses VLAs might actually have had, they are gone with C11.

Well, they're a conditional feature now, you are supposed to check __STDC_NO_VLA__.

Which basically means that outside gcc and clang based compilers, __STDC_NO_VLA__ will be false, for example on MSVC or IAR Embedded Workbench.

Reply on news.ycombinator.com