SIsigna11·Mar 28, 2026Submission
C Preprocessor tricks, tips, and idioms
3 points · Open discussionpfultz2
Cloak
C2013–2026
pfultz2 / Cloak
Cloak
A mini-preprocessor library to demostrate the recursive capabilites of the preprocessor
8Distinct people
10Mentions
0Explicit recommenders
989GitHub stars
What to know before exploring
What it is
A mini-preprocessor library to demostrate the recursive capabilites of the preprocessor
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year10 dated mentions
Observed mentions: 2013-06-27 19:27:14 UTC to 2026-03-28 07:06:29 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
10 sourcesC's is weak yet not weak – you can do various advanced things (like conditional expansion or iteration), but using esoteric voodoo with extreme performance cost. Whereas other preprocessors let you do that using builtins which are fast and easy to grok.
See for example https://github.com/pfultz2/Cloak/wiki/C-Preprocessor-tricks,...
Poor C preprocessor performance has a negative real world impact, for example recently with the Linux kernel – https://lwn.net/Articles/983965/ – a more powerful preprocessor would enable people to do those things they are doing anyway much more cheaply
In Greppability is an underrated code metric> Without syntax to say "this is an object",
How about this syntax?
#include "oo.h"
DEFINE_CLASS(Counter,
int METHOD(Counter,getValue,NO_ARGS);,
void METHOD(Counter,increment,NO_ARGS);,
void METHOD(Counter,decrement,NO_ARGS);,
void METHOD(Counter,multiplyThenAdd,(int multiplyBy, int add));
);
That's valid C, given appropriate preprocessor macro definitions.
It is a bit ugly, due to the limitations of the C preprocessor.
(Maybe someone else can do better than me.)
If C had a more powerful preprocessor, but was otherwise unchanged, the syntax could be a lot nicer.
The DEFINE_CLASS() macro expands to declare a function:
Counter* newCounter(void);
Why isn't the return value of that function an object?
Here is the contents of "oo.h":
#include "cloak.h"
#define JOIN(...) JOIN_IMPL(__VA_ARGS__,
Read the rest
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,)
#define JOIN_IMPL(_1,_2,_3,_4,_5,_6,_7,_8,_9,_10,_11,_12,_13,_14,_15,_16,_17,_18,_19,_20,_21,_22,_23,_24,_25,_26,_27,_28,_29,_30,_31,_32,_33,_34,_35,_36,_37,_38,_39,_40,_41,_42,_43,_44,_45,_46,_47,_48,_49,_50,_51,_52,_53,_54,_55,_56,_57,_58,_59,_60,_61,_62,_63,...) \
_1 _2 _3 _4 _5 _6 _7 _8 _9 _10 _11 _12 _13 _14 _15 _16 _17 _18 _19 _20 _21 _22 _23 _24 _25 _26 _27 _28 _29 _30 _31 _32 _33 _34 _35 _36 _37 _38 _39 _40 _41 _42 _43 _44 _45 _46 _47 _48 _49 _50 _51 _52 _53 _54 _55 _56 _57 _58 _59 _60 _61 _62 _63
#define DEFINE_CLASS(name,...) \
typedef struct name name; \
typedef struct name { \
void *_privateData; \
JOIN(__VA_ARGS__) \
void (*destroy)(name**); \
} name; \
name* new##name(void)
#define METHOD(class,method,args) \
(*method)(class* COMMA_IF(IS_PAREN(args)) WHEN(IS_PAREN(args))(EXPAND(EXPAND args)))
#define NO_ARGS
Where cloak.h is https://github.com/pfultz2/Cloak/blob/master/cloak.h
The above macros are admitttedly very hairy. If C had a better preprocessor, but was otherwise unchanged, they could look a lot nicer.
> I never said such a thing. Would appreciate if you didn't put words in my mouth.
A normal part of dialogue is, "I'm going to repeat your point back to you in my own words, and you can either agree with my restating of it, or point out at which point I've misunderstood you". That's what I was doing. "Would appreciate if you didn't put words in my mouth" is unnecessary hostility.
> In my concrete example, given that FILE and DIR were classified as objects, to which of the so-called objects does F(const char*, FILE, DIR) belong?
Take any language which you agree is "OO". Add one new feature (if it isn't already there): functions/methods which don't belong to any class/object. Now the function you are talking about is possible in that language. Did the language thereby suddenly cease to be OO when we added that feature? Most people would disagree with "Yes". But if "No", what is the actual difference between C and that language?
> I use this pattern so much I actually wrote a little metaprogramming language that is capable of generating a lot of the boilerplate for you. Link in my bio, if anyone's interested in looking at it.
Your language [0] is an interesting idea. I've done a lot of similar stuff (not at work, I'm very rarely asked to write C code professionally, but I like mucking around with it in my personal time). My own approach to C metaprogramming involves obtuse preprocessor hacks (e.g [1]) and shell scripts that use grep/awk/sed to find macro invocations and spit out new header files as a result. Maybe your way is better.
A word of warning though – do you realise your name for your language is an anti-gay slur in several dialects of English? You might end up unintentionally upsetting some people with it.
[0] https://github.com/scallyw4g/poof
[1] https
In Plain C API design, the real world Kobayashi Maru testWell, mostly I use idioms from the Cloak Wiki (https://github.com/pfultz2/Cloak/wiki/C-Preprocessor-tricks,...). It takes some time to realise them :)
In Datatype99: C99 with Sum Types, v0.1.0C preprocessor tricks, tips, and idioms (2015)
78 points · Open discussionDeferred expansion is a common (well, not that common) trick this misses that I would have included. Generally the C preprocessor is pretty terrible though, you should seriously consider generating code with an external tool before doing anything nontrivial with it.
Regardless, here's a link that seems to cover this and other somewhat more obscure techniques: https://github.com/pfultz2/Cloak/wiki/C-Preprocessor-tricks,...
In C preprocessor tips and tricksWow, I just finished doing something similar. The use of x-macros is definitely a little cleaner / canonical than my approach, which instead "recurses" through a VA_MACRO. For an excellent guide on recursion in macros, see this article on how to abuse the C pre-processor: https://github.com/pfultz2/Cloak/wiki/C-Preprocessor-tricks,....
In the end I end up defining structs like this:
SERIALIZER_STRUCT( structname, int8_t, field1, int16_t, field2, ... );
Initializing them like this:
structname instance = {.field1 = 1, .field2=2};
and serializing them like this:
SERIALIZER_SERIALIZE( structname, &instance, bigbuff_ptr );
As for just using a packed structure, there are definitely caveats with some compilers (ie: compilers for embedded systems may not handle various edge-cases for misaligned access, particularly when dereferencing pointers to
Read the rest
structs.)
The hygienic C macro is broken. It breaks if your variable happens to already be named "tmp": swap(x, tmp). This would work however:
#define SWAP(x, y) { \
typeof (x) x##y = x; \
x = y; \
y = x##y; \
}
Also, you can be tricky and "co-recurse" in macros, which is explained here: https://github.com/pfultz2/Cloak/wiki/C-Preprocessor-tricks,...
Regarding each-it, I think its pretty doable in C. Right off the top of my head, this seems to work:
#define eachIt(myArray) typeof(myArray[0]) it; for (int i = 0; i < sizeof(myArray)/sizeof(myArray[0]) && (it = myArray[i], 1); ++i)
This can now be used just as in the example:
struct test_ { int one; double two; };
typedef test_ test;
test array[17];
eachIt(array) {
it.one = 1;
it.two = 0.2;
}
However, I believe(?) th
Read the rest
at it depends on the version of the C standard whether this is hygienic or not. When I compile in GCC it certainly works fine because the i is counted as internal to the for loops scope, but I'm not sure that's always the case. There is also the separate question of whether "it" should be hygienic or not.
C Preprocessor tricks, tips, and idioms
16 points · Open discussion