33 ms·
This feels very niche. Typing the \ at the end of multi-line macros is something many editors help with (and forgotten \s are visible in syntax hilighting.) B
by eqvinox 5y ago
This feels very niche. Typing the \ at the end of multi-line macros is something many editors help with (and forgotten \s are visible in syntax hilighting.) Binary inclusion is frequently just a small build script. Deferred resource release is already available as a GCC/clang extension, so it's only for less capable compilers as you say yourself.
That leaves the @ operator… which seems useful for specific cases (e.g. graphics rendering), but I can honestly say I don't really feel a need for that in the codebases I worked with.
But. Let me offer some suggestions for extensions! :)
An improved preprocessor would be massively useful if it had features like:
- enumerating struct members in preprocessor macros (something like:)
#define MACRO2(typename, fieldname, arg1, arg2) ... arg1 arg2 ...
#define MACRO(typename, arg1, arg2) something { #each-member(MACRO2, typename, arg1, arg2) }
struct bla {
int a, b;
}
MACRO(struct bla, x, y)
/* => something { MACRO2(struct bla, a, x, y) MACRO2(struct bla, b, x, y) } */
- same, for function parameters
- and last but not least, macros consuming { } blocks, e.g.
#define MACRO(...)#{name} something something #{name} something #{name}
MACRO(1,2,3) {
this block is consumed by the macro and placed in 2nd and 3rd #{name} (first one just signals the macro consumes a {} block
}
...oh and, almost forgot, "extensible" macros:
#define MACRO(...) abc
#ifdef MACRO
#extend MACRO(...) def MACRO(...) ghi
#else
#define MACRO(...) def stub ghi
#endif
(also, macros that can define other macros. Like _Pragma() => #pragma, _Define() => #define)
- yvdriess 5y ago+1 on the macro-time iteration. The hacks I found to do it are just too unwieldy to justify their use.
- kevin_thibedeau 5y agoPretty straightforward with m4.
- eqvinox 5y agoCan't tell if this is a joke or not. Sure hope it is. If it isn't — the number of people who understand m4 well enough to be able to maintain something like this can probably be counted on a few hands.
- eqvinox 5y agoYeah, everything I posted there is based on something I had to do at one point or another, and none of it was pretty. (Some ugly enough to have decided against it even though it was done and working.)
- arthur2e5 5y agoThe struct enumeration thing is certainly useful for homogenous vectors being written as structs, but one of the issues is that it requires the preprocessor to have significantly more knowledge of the underlying language. Would it be a better idea to have something generate X Macros from struct defs instead?
- eqvinox 5y agoYeah, the enumerations require the preprocessor to understand the language and process the struct definitions... which may not even exist yet if they contain macros :D. It's not an easy problem. Generating some kind of macro-usable list like you suggest is probably the way to go, essentially making the entire thing a 2-pass process. (That said, the C preprocessor doesn't have a concept of "lists", perhaps that's the thing to actually add here.)
- AlbertoGP 5y ago> enumerating struct members in preprocessor macros (something like:) I considered something along these lines: my main use case would be to produce string versions of enum values, like Rust’s «#[derive(Debug)]». The problem is that, without type information, it would be too fragile, so I decided to leave it out. Still, I’ll consider what you propose, maybe there is some form of purely syntactical macro that could cover these use cases.
- eqvinox 5y ago> The problem is that, without type information, it would be too fragile, so I decided to leave it out. typeof() is being considered for ISO C2x and has been around for ages in GCC/clang. _Generic is already in C11. With a struct member iterator, these 2 could/should be useful to branch out into type specific handling for each field. Admittedly those are somewhat limited, particularly when working with typedefs, but that's a bit of a fundamental problem in C :(