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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-10-25 06:30:09

Hi,

Aristid Breitkreuz wrote:
> Hi,
> 
> too funny I recently implemented named parameters for macros, too. But
> differently and specialised (no general-purpose framework or anything -
> not because it were not doable, but because I didn't need it).

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.

> 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.

> The idea is "simple": 
> 1. Generate a valid PP-Sequence from this "tuple-sequence"-thing
> 2. Generate a set of "modifications" by looking up the value of PARAM_
> ## param (x), which will expand to (index, x) or something like this.
> 3. Apply those changes to an initial tuple.
> 4. Use the tuple to invoke another macro.

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).

> I do not know which approach should be considered superior. But I really 
> consider both interesting. 

Indeed! 

> I used my approach in a usable C++ library already, so the concept 
> (which is the same for both) _is_ practical.
> 
> Kind regards,
> 
> Aristid
> 
> 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.

Thanks a lot for the inspiration. 

Regards,

Tobias