Macros on Steroids: How pure C can benefit from metaprogramming • Hacker News Board

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#61

Post by gsmecher » Fri, Jul 23, 2021, 5:26 PM UTC

mumblemumble wrote: post #59

spaetzleesser wrote: post #50

Earlier quoted context omitted.

For example INotifyPropertyChanged which is used in WPF. The typical implementation is something like this: public string CustomerName { get { return this.customerNameValue; } set { if (value != this.customerNameValue) { this.customerNameValue = value; NotifyPropertyChanged(); } } } When you have 20 properties you have a ton of repetitive code. With a preprocessor I could reduce each property to a one liner. You can…

Yeah, there is that, but I wash hoping to see a great use case for C preprocessor macros. WPF data binding doesn't seem like good candidate for something you're likely to want to do in a C program. Or were you really just meaning to advocate for metaprogramming in general?

I design instrumentation for telescopes, in which C code on an embedded processor peeks and pokes device registers on an nearby FPGA. This C code forms an interface between hardware and the network.

In this system, I write a given function in C and surround it with a macro wrapper. This wrapper generates a JSON-RPC equivalent of the C function using the Jansson JSON library [1], complete with argument typechecking and error management. My C code can call the function normally, and an embedded webserver [2] can export it across the network where it's used fairly transparently by a Python stack on a control PC.

All three of these "embedded software" elements (the embedded webserver, the JSON library, and the FPGA interface) are very well suited to C. I have recently dabbled in moving parts of it to C++, and have found a few surprising impedance mismatches. (As I mentioned above, C++ still lacks reflection.)

The macros, here, are not for "elegance" or any other abstract purpose. They have allowed a ~80% reduction in boilerplate and an equally impressive reduction in the bugs and hassles associated with this kind of low-density, high-sprawl code.

[1]: https://digip.org/jansson/

[2]: https://www.gnu.org/software/libmicrohttpd

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#62

Post by glouwbug » Fri, Jul 23, 2021, 6:46 PM UTC

lhorie wrote: post #8

Something 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…

Templated C is totally possible. It’s just a little verbose, but you get used to it. For instance, an alternative to void pointers while maintaining compile time type safety and gaining speed and maintainability looks something like this:

github.com/glouw/ctl

Check CTL/vec.h, for instance

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#63

Post by nomel » Fri, Jul 23, 2021, 6:52 PM UTC

tpoacher wrote: post #58

nomel wrote: post #29

Earlier quoted context omitted.

> vs learning curve for contributors Early on in my programming career, I implemented all sorts of beautiful magic, but I was alone. Later, I realized that beautiful magic was keeping me alone. Now, much later in my career, I program mostly like a novice. I don't write clever code, I unroll powerful one liners into boring for loops, and I use all sorts of temporary variables to make intent perfectly clear, because I…

Simplicity is elegance.

"Simplicity" is also not well defined, and seems to be very very different for a novice or more advanced coder. Many seem to think fewer lines of code means simpler, or chaining 20 lines/calls is clearer than temporary variables, or use lambdas everywhere is better since function definitions are harder to grok. From my experience, elegance is often something very clever, and elegant by definition, but also nearly impossible to understand.

So, I guess "simplicity in understanding".