5 ms·
TLDR of why less cluttered preprocessor output matters? I’d say cpp output is usually not that interesting on a daily basis.
by sigjuice 9y ago
TLDR of why less cluttered preprocessor output matters? I’d say cpp output is usually not that interesting on a daily basis.
- bluetomcat 9y agoIf 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 9y agoWhich 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...
- roywiggins 9y agoI guess it standardizes your boilerplate at write-time even if you have to review it expanded.
- sjmulder 9y agoThe 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.