|
Boost : |
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-15 06:01:26
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams
> > PY_DEFINE_CONSTANTS_NO_EXPANSION((foo)(bar) BOOST_PP_INTERCEPT_)
> >
> > The trick here is to get the sequence inside the machinery in a way
> > that allows the machinery to prevent it from expanding. That's the
> > trailing 'INTERCEPT_ and the 'seq ## 0'. From there, it can be
> > immediately processed with custom sequential iteration to
> make a new sequence with a argument/string pairs.
>
> According to
> http://www.boost.org/libs/preprocessor/doc/ref/intercept.html
> there's no trailing underscore. Am I missing something?
I'm cheating a bit. INTERCEPT expands to INTERCEPT_, which expands to nothing
when a number is pasted to the tail. In this context, INTERCEPT won't expand in
time, so you'd get INTERCEPT0, which won't expand at all (because it isn't a
macro), rather than INTERCEPT_0 (which will).
The library is not designed to allow for the sort of timing required for delayed
invocation. Rather, it is intentionally designed (in most cases) to allow
arguments to expand on input. Plus, not only is it impossible to do portably,
it can quickly become a vertical dependency nightmare because macros start
expanding in contexts that they weren't designed to expand in. I.e. the
implementation details of macros, in particular, become subject to the
environment context (i.e. what macros are currently disabled). Chaos has
limited support for this type of thing, but it really is limited. What you can
do in these contexts becomes severally restricted with respect to what other
library primitives you can use. One thing that you can do safely, relative to
expansion timing, is delay invocation all the way through some other macro
(several ways to do this). But it is dangerous to make something expand some
arbitrary number of steps into another macro expansion.
Regards,
Paul Mensonides
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk