My not-so-humble opinion is that if you're using the C preprocessor to do metaprogramming, you have outgrown C and need a more powerful language.
I humbly agree unless, of course, there is no other solution, e.g. lack of compilers on your platform.
Macros on Steroids: How pure C can benefit from metaprogramming
11–20 of 63 posts
Re: Macros on Steroids: How pure C can benefit from metaprogramming
#12Earlier quoted context omitted.
If you need these kinds of advanced metaprogramming capabilities then I feel like that's a sign that maybe plain C isn't suitable for your project and you'd better off switching to Zig, Rust, D or C++. These all provide powerful compile-time execution capabilities and the ability to expose C interfaces.
Only if you can switch to something like Zig, Rust, etc. But a tremendous amount of code bases are already written in plain C. Using preprocessor metaprogramming allows you to invoke macros right in the same files in which you write ordinary C code, without the need for integration with other languages.
To date, C's most proximate (management-friendly, technically similar, programmer-skill-adjacent) competition has been c++. (I'm trying to lay the groundwork for the next statement: I'm not claiming this is good, and excited to see Rust and friends as serious contenders. Stay with me.)
Even in c++20, there are things you can do with macros you can't do in the language. This may change when reflection lands in c++2x, but I won't be able to use it for years and widespread adoption won't be possible for another decade.
Re: Macros on Steroids: How pure C can benefit from metaprogramming
#13There are good reasons to reach for macro libraries. They're rare, but they're out there. I make heavy use of boost::preprocessor in a C project and it was fundamentally enabling. I have occasionally cursed at it but never regretted it. It is basically impossible to provide a "kind" development environment using deep macro trickery. The error messages you get from this kind of library are a major handicap. This faili…
If you need these kinds of advanced metaprogramming capabilities then I feel like that's a sign that maybe plain C isn't suitable for your project and you'd better off switching to Zig, Rust, D or C++. These all provide powerful compile-time execution capabilities and the ability to expose C interfaces.
Even those may not be powerful enough. I have a use case where I was trying to read specification files to generate unicode tables. But using something like zig's @embedFile to get a handle to a []u8 in a comptime block doesn't work because I don't want the file to be embedded into the binary; I want something more akin to turing complete code generation. And I don't need it to run it on every compile, as the entire flow involves downloading said files off the internet, but only when a new version of the spec is released. I ended up just using code generation.
Re: Macros on Steroids: How pure C can benefit from metaprogramming
#14Something about macros that I don't see discussed much is the trade-off between improved clarity of intent vs learning curve for contributors. I don't have a ton of experience w/ C, but the large projects I've seen appear to have a tendency to avoid heavy macro usage (e.g. using `void *` for hashmap implementations instead of reaching for macros, for example). I see macros appear more frequently among those that prio…
I'm currently using Datatype99 & Interface99 at work.
What can I say? Everything goes well, nothing critical has appeared soon, my coworkers are able to understand the code.
Regarding macro-based eDSLs, I would not resort to them for needs other than abstractions to be considered as a part of the language (ADTs, interfaces, etc.), since they are like languages on their own; when you try to understand/contribute to eDSL-based code, you have to understand its syntax and semantics, aside from how does it actually solve a particular problem in the problem domain.
In fact, as for now, I don't see much need in something like Metalang99 except for Datatype99 & Interface99 (and probably my feature request to libmprompt [1]).
Re: Macros on Steroids: How pure C can benefit from metaprogramming
#15There's also libCello[1] which provides useful abstractions. Though, at this point I think choosing Zig[2] programming language which allows to write compilation-time logic in the same language as the runtime is preferred.
Re: Macros on Steroids: How pure C can benefit from metaprogramming
#16My not-so-humble opinion is that if you're using the C preprocessor to do metaprogramming, you have outgrown C and need a more powerful language.
See this comments branch: https://news.ycombinator.com/item?id=27921095.
Re: Macros on Steroids: How pure C can benefit from metaprogramming
#17Earlier quoted context omitted.
Only if you can switch to something like Zig, Rust, etc. But a tremendous amount of code bases are already written in plain C. Using preprocessor metaprogramming allows you to invoke macros right in the same files in which you write ordinary C code, without the need for integration with other languages.
> Using preprocessor metaprogramming allows you to invoke macros right in the same files in which you write ordinary C code C++ effectively lets you do this too. And Zig will let you import and compile C files seamlessly. I suppose you have to switch compilers, but that's not so different to adding the additional pre-processor compiler.
C++ can, fair. Still there is a huge amount of developers sticking to plain C, even if they can use C++ (FFmpeg, VLC, Linux, etc.), why do they do that? I think an answer to this question would be pretty much the answer for the initial question. There might be cultural, historical, and other reasons for it.
The thing with Zig is that, if I understand it correctly, Zig can't be interleaved with other C code in the same file, which forces you to separate things, loosing convenience. On the other hand, to use Datatype99, you can just #include and you're ready to go.
Re: Macros on Steroids: How pure C can benefit from metaprogramming
#18There's also libCello[1] which provides useful abstractions. Though, at this point I think choosing Zig[2] programming language which allows to write compilation-time logic in the same language as the runtime is preferred. [1] http://libcello.org/ [2] https://ziglang.org
Zig is an interesting alternative to C.
libcello has quite different philosophy than Metalang99 and the accompanying libraries like Datatype99. The thing is that the former comes with its own runtime environment, but the latter ones even don't require the standard library. I believe the philosophy of C is closer to Metalang99/Datatype99/Interface99.
Re: Macros on Steroids: How pure C can benefit from metaprogramming
#19Can anyone with some real experience with this comment on the debug visibility? In gdb or lldb or otherwise? How easy is it to see what is going on, partially expand macros, get at intermediate values, or evaluate things at the debug prompt? At first glance it seems like it'd be quite obfuscated but perhaps I will be pleasantly surprised by some experience reports.
Re: Macros on Steroids: How pure C can benefit from metaprogramming
#20You could create this as a frontend macro preprocessor that implements new language constructs. Maybe it could be called cfront. I just hope that the usefulness of that doesn't lead to bloated and complex codebases and binaries as features are added to the preprocessor.