From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-12-29 21:19:30
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Arkadiy Vertleyb
> The typeof library defines a macro, REGISTER_TEMPLATE, that
> is intended for use by the library users. Once people
> started using the library, they eventually wanted to use this
> macro inside the Boost PP looping constructs, such as
> SEQ_FOR_EACH, etc.
> Since the implementation of REGISTER_TEMPLATE itself uses
> quite a few looping constructs, people ran into re-entrancy issues.
Which looping constructs does it use?
> I would like the users to be able to use the macro with
> whichever looping construct they prefer, and, AFAIU, the
> easiast (only?) way to achieve this would be to limit the
> macro implementation to only use automatically re-entrant
> macros, such as BOOST_PP_REPEAT.
That depends. If you can (re)specify the implementation in terms of only one
"recursion state" (such as 'z' for REPEAT), then it is best to provide both:
#define REGISTER(...) REGISTER_Z(DEDUCE_Z(), ...)
#define REGISTER_Z(z, ...) // ...
If the implementation requires (or is significantly better using) multiple
states, then, yes, you should have it do everything automatically.
> Is this the right way to go for this particular case, and
> generally for any macro that is in the library interface?
That's the general answer. The pp-lib fails to provide a unifying way to deal
with recursion, which is why these problems pop up from time to time.