3 ms·
Nice to meet you! Thanks for the nice words, my program is much more modest than cmacro :-) Yes, I think that the transform you describe would require the pro
by AlbertoGP 5y ago
Nice to meet you!
Thanks for the nice words, my program is much more modest than cmacro :-)
Yes, I think that the transform you describe would require the processor to know about types, which is something I avoided here. I experimented early with writing a function that would track the types of things and enable smarter macros, but it became obvious that it was going to be a choice between writing a full compiler frontend and a hacky thing that worked only in trivial cases, so I discarded it.
The decision was to keep it as a naïve macro processor, just with a minimum understanding of C syntax, and leave out anything that requires taking into account the semantics.
I have other macros that do things like expanding «obj[a..b]» to «(Slice){.start_p=&obj[a], .end_p=&obj[b] }» but they are not worth it, because to work smoothly they would need to know the type of «obj». If absolutely needed, I think that «_Generic» could be used here but it starts complicating things beyond the point of diminishing returns.
- zetalyrae 5y agoYou can get quite far with a preprocessor that's completely unaware of the semantics of the code. Or that trusts the programmer to use the macros on constructions of the right type. Even parsing C "correctly" is a huge problem, since the syntax is ambiguous and the ambiguity can only be resolved by keeping a symbol table that tracks what kind of thing a symbol is. So there's a huge pragmatic force to keep a strict separation between a type-unaware preprocessor and a full-blown compiler frontend. (I considered using clang to dump the C AST when building cmacro, but concluded it would be too unwieldy.)