Macros on Steroids: How pure C can benefit from metaprogramming

Re:Macros on Steroids: How pure C can benefit from metaprogr... by enhray on Thursday July 22, 2021 @03:22PM (#27923052)

The C preprocessor is definitely ill-suited for metaprogramming, but it was never the C way, was it?

The traditional way to do any kind of meaningful metaprogramming in C is just a printf() to a .h or .c file which then is included to your build.

There are a lot of projects doing that. Bison is supposed to be used this way, other projects are doing build configuration like that - by emitting a header with a ton of #define’s, and there’s a ton of languages which use C as a compilation target - and you can see what they are doing and get inspiration from that.

In my opinion it’s an extremely powerful model, much better than anything you can do with the preprocessor.

[ Parent | on HN ]

Re:Macros on Steroids: How pure C can benefit from metaprogr... by Hirrolot on Thursday July 22, 2021 @03:38PM (#27923240)

If we are talking about such abstractions as Datatype99, this model is less convenient than native macros [1]. You have to write code in separate files, IDE support is lacking, sophisticating a build procedure, etc etc.

[1]: https://github.com/Hirrolot/metalang99#q-why-not-third-party...

[ Parent | on HN ]

Re:Macros on Steroids: How pure C can benefit from metaprogr... by enhray on Thursday July 22, 2021 @03:49PM (#27923415)

Native macros were never supposed to be used that way. If anything goes wrong, you still have to deal with that, and no IDE will save you from having to invoke your compiler with “preprocess-only” flag to see what you’re dealing with. Been there, done that, don’t want to do that ever again.

Compared to that, debugging generated code is a breeze.

Also, there’s no “third-party” generators - everything just lives in your own source tree. If I ever need to go meta, it’s just a printf away; I can even commit the generated files to my VCS and be able to see what had changed in them between commits in a simple and understandable diff.

Regarding the integration, I’ll take setting up an additional build phase (once) over having to debug C macros any day.

[ Parent | on HN ]

Re:Macros on Steroids: How pure C can benefit from metaprogr... by Hirrolot on Thursday July 22, 2021 @04:00PM (#27923568)

> Native macros were never supposed to be used that way. If anything goes wrong, you still have to deal with that, and no IDE will save you from having to invoke your compiler with “preprocess-only” flag to see what you’re dealing with. Been there, done that, don’t want to do that ever again.

~95% of errors from Datatype99 can be observed from the console, I hardly ever run my compiler with -E. What I mean by IDE support is that you invoke macros in the same files in which you write ordinary C code, you can't do that with printf. Imagine that you write your tagged unions (datatype(...)) inside separate files, it's clearly less convenient than embedded definitions.

> Regarding the integration, I’ll take setting up an additional build phase (once) over having to debug C macros any day.

I can't remember the time when I debugged already written and tested macros from Datatype99/Interface99, to be honest.

[ Parent | on HN ]