Hacker News Reader

Comment by GartzenDeHaes | Hacker News Reader

The best C programming trick is to use no tricks. Making your code as boring and plain as possible greatly reduces bugs and increases productivity.

View on HN

  > The best C programming trick is to use no tricks.

Yes! C's monotony is its killer feature. Take away power when you are coding and you have more power to share the code and debug it.

I agree wholeheartedly. I may be called a hater and I may be raining on everyone's parade, but I opened this thread expecting to find horrors and I did (plenty of metaprogramming).

The very notion of there being tricks and that knowing them makes you better is something I hate about C and C++. Most tricks I read here are bandaids over usability issues the languages have. Yes, they alleviate an issue but may introduce unexpected consequences and distance your dialect from the rest of the community.

I am so very thankful that C and C++ are no longer the only options for low level, non garbage collected programming.

As an embedded C developer, I'm interested. What do you recommend looking into as other "low level, non garbage collected" options?

I imagine they are referring to Rust.

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, });

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.

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.

Reply on news.ycombinator.com