Re: [boost] [preprocessor] use case: named parameters for macros

From: Aristid Breitkreuz (aribrei_at_[hidden])
Date: 2006-10-26 13:23:20

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