[sigjuice]

TLDR of why less cluttered preprocessor output matters? I’d say cpp output is usually not that interesting on a daily basis.

[bluetomcat]

If I have a file like this:

    #include <stdio.h>
    #include <assert.h>
    #include "mydefs-control.h"
    #include "mydefs-value.h"

    int main(void) {
        assert(1 == 1);
        printf("%d\n", MYDEF_VALUE_MACRO);
        MYDEF_MACRO_WITH_CONTROL_FLOW();
    }

My goal is to produce output which doesn't include thousands of lines from stdio.h and assert.h, doesn't expand assert() or MYDEF_VALUE_MACRO, and only expands MYDEF_MACRO_WITH_CONTROL_FLOW:

    int main(void) {
        assert(1 == 1);
        printf("%d\n", MYDEF_VALUE_MACRO);

        if (1) {
            return 0;
        } else {
            return 1;
        };
    }

According to the author, having only the "interesting" stuff expanded makes it easier to reason about the control flow of the code.

[dummyfunnytoo]

Which just raises the question for me, why have the macros at all? I did C++ development for years (on low level and performance sensitive applications) but 95% of the macros I saw were there to reduce lines of code or "eliminate boilerplate." Almost all of those could be eliminated by refactoring within C++, without resorting to the preprocessor, but developers love using macros...

[sjmulder]

The article is about C where not everything can be solved with a typedef, enum or templates. Think about feature macros (e.g. _C_POSIX_SOURCE), generics (pre-C11 or what was it), attributes or calling conventions, conditional compilation, function-like macros, compatibility (e.g. errno when it isn't just an extern int), and indeed shorthands.

[roywiggins]

I guess it standardizes your boilerplate at write-time even if you have to review it expanded.