> hm, maybe that's where all the basedware is
the cube-headed menace actually does this quite frequently, showing up to some shitty conference to give a shitty talk about shitty buzzword shit in a shitty kermit voice
im subscribed to NDC Conferences, because I like listening to talks sometimes, and this showed up in my subscribed feed
well thats what you get for taking advice from @analrapist
CHARGE PUMP 0x14 DISPLAY ON, but he doesn't do that either (???????)
I'm not sure what you're after here. C generated source engines? That makes it sound that compilers that compile to C, like Mercury-language, would fit the bill. Can you elaborate on what you're asking here?
They're text template engines that allow you to generate C code programmatically, as I mentioned, Bison, Flex, and autoconf are all examples of it. Maple also has a built-in function for this. It's essentially templates in the most antiquated sense. They're not at the level of a transpiler, they're deliberately simple to avoid overcomplicating codebases, but they're designed to streamline boilerplate, like if you were creating linked lists of a given type.
I guess my perspective is that I'd prefer a structured tool for code reuse over preprocessor abuse, I've become increasingly conservative with how much I employ macros as I've gotten older. I think so long as the tool is deterministic and isn't introducing a bunch of hidden behavior, it's not a huge issue. From what I've read, most of them utilize
#line directives to allow for the debugging to approach something sane, which I think is a plus.
I am a fellow C dev, and while I will use the preprocessor, I do consider it kind of a misfeature. My main C project is in the Suckless style, with config.h. But straight substitution #defines mostly. The correct route is something like zig's comptime, IMO. The most aggressive I get with preprocessor defines is something like #define ERROR(msg) printf("%s is a nigger | %s:%d",msg,_FILE_,_LINE_) (Actually, it's a bit uglier because VARARGS. But conceptually straightforward.)
You'd love C23, you can just do this now.
__VA_OPT__(x) only inserts its argument if __VA_ARGS__ is non-empty. Lot of great stuff in this standard honestly.
For me, the peak is how I can redeclare structs so long as the layouts and field names are the same, you can remove a lot of boilerplate just by making macros to define them in place.
I see you're enlightened. C pairs great with those Unix-y text-in text-out tools. It's almost like they're meant for each other, like C was designed simultaneously with Unix. Lisp fags seethe when your tell them this kind of code transformation is more powerful than Lisp macros.
Some years ago the D language deprecated binary literals because "nobody uses it". In most cases just using the hexadecimal representation is just as understandable while being way more compact. All C programmers should know what 0x80 means, hell I've seen code that does int&255. Even for less common bit patterns like 0x55 and 0xAA (alternating bits) just adding a comment explaining the binary representation suffices.
I usually call them "source code generators" because people usually get the idea.
I love Flex and Bison. Surprisingly handy tools, especially Flex.
That seems to be the general consensus, but in a more radical way. That's how we ended up with backend js, node cli apps and electron start-menus.
When will D deprecate itself then?