Products > Programming

Macro functions in headers

<< < (5/5)

SiliconWizard:

--- Quote from: dunkemhigh on December 02, 2021, 10:06:57 pm ---Sure, but it's like leaving live wires hanging from the roof - of course you're not going to grab them so they're not a problem. But we wouldn't be seen dead (sorry!) doing it.

--- End quote ---

Frankly, unless you're writing an API for others to use, or are expecting this piece of code to be maintained by many developers over the next decades, it won't make a difference.
Just because it would be exposing those helper functions to the caller doesn't mean you have to use them. Nothing is hanging. As much as I like hiding and encapsulating, you're probably overthinking it here.

That said, all in all I prefer Nominal Animal's approach for your need here. My proposal is more adapted to functions that do not have external dependencies, and that are possibly called very frequently - and most of all, that potentially all have a different argument list. In your case, it's always the same and only the name of the function differs, which makes Nominal's approach easier and a lot more consistent.

brucehoult:

--- Quote from: dunkemhigh on December 03, 2021, 12:13:14 am ---
--- Quote ---It should be possible to avoid the need for OS specific generator scripts by using X-macros
--- End quote ---

Thanks. Looks like the thing that Bruce described - not heard the term xmacro before, but it's descriptive.

--- End quote ---

Ha! Exactly the same, yes.

I didn't know it had a name. Or that someone had done it before (but it's unsurprising).

Preprocessor ab-uuuuuuse

I'm pretty certain the ugly hacky preprocessor is 90% of the reason C beat the Wirthian languages outside of the Unix environment.

80% of early C++ was getting rid of preprocessor hacks, one by one.

SiliconWizard:

--- Quote from: brucehoult on December 03, 2021, 02:00:09 am ---80% of early C++ was getting rid of preprocessor hacks, one by one.

--- End quote ---

And then replacing it with even uglier stuff. :P
Of course that's a bit tongue-in-cheek, but point is, many languages with a C root that have tried getting rid of the preprocessor have come up with a bunch of stuff that, when it eventually gets to the point of being as flexible as the original preprocessor, becomes horribly convoluted.

dunkemhigh:

--- Quote ---I like to do this for (embedded) configuration parsing.  Then, the hash table strings are configuration keys, and the values are pointers to the data, and the value-parsing function and its parameters in an union, so that although each configuration value is parsed using a single function, there only needs to be one per parameter type, instead of one per parameter.
--- End quote ---

I might be drifting towards this kind of thing. But probably I think I will more likely try each approach and see how they turn out.

dunkemhigh:

--- Quote ---Unless you were going to call those functions extensively in time-constrained parts of the code, which I doubt here
--- End quote ---

If there is any constraint it would be towards code size. They would typically be called at init, and if a time-sensitive section needed repetitive access it would cache a copy.

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version