Am Mittwoch, den 25.10.2006, 12:30 +0200 schrieb Tobias Schwinger:
Hi,
Hi, for short: I hereby provide a sample implementation with (possibly) room for optimization and sub-optimal macro names. Consider it a proof of concept and further inspiration. If there is demand, I can license it permissively.
[snip] Well, the experiment was driven by the question whether it would be possible to add more features of spirit::rule to a macro-based replacement that uses typeof instead of virtual dispatch (see boost/spirit/utility/rule_parser.hpp, note: no named parameters in there, yet) without compromising the interface or even making it better.
Oh. Virtual dispatch is still necessary for recursion, right? This is surely a complex topic.
Nevertheless, they are used like this
MACRO((foo, 77) (bar, int))
which will expand to say
MACRO2(int, 77)
Nice! I like this kind of interface, because parameter names do not have to be full-blown macros (which will need a potentially verbose disambiguation prefix in real life). I think, I'll adopt it.
Yeah that's something I recognized while implementing it :D.
[snip]
Interesting. That approach would allow a usage like
#define MY_MACRO(args) \ NAMED_PARAMS_MACRO(MY_MACRO_IMPL,(bar,1st_default)(foo,2nd_default), args)
which I happen to like. I think I'll adopt this one, too (although I'm not sure about the implementation).
An adaptation of which I hereby provide.
[snip]
PS: I do not think preprocessor metaprogramming should be over-used
but
there are a few places where it fits nicely.
Here's my rule of thumb on this issue:
If you have the choice between the preprocessor and another language feature, prefer the other language feature, unless it really hurts to do so. If you have the choice between the preprocessor and an external code generator, prefer the preprocessor unless it really hurts to do so.
That's what I already did intuitively so I'm fine.
Thanks a lot for the inspiration.
Regards,
Tobias
Regards, Aristid