Boost logo

Boost :

Subject: Re: [boost] BOOST_PP array extension proposal
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2015-09-11 23:26:48


> Speaking of Chaos, I know I try to bring this up whenever you make an
> appearance, but can you please put Chaos up for review? I don't know the
> status of which compilers can handle it without workarounds, but as long
> as
> a compliant compiler can handle it, that's good enough for Boost, and you
> can just choose to not support broken implementations. One problem that I
> run into with Boost.Preprocessor is that since I can't "recurse" with
> BOOST_PP_SEQ_FOR_EACH I have to frequently use some other repetition
> construct instead, and I'm sure that I'm paying for that decision. This is
> particularly a problem if the macro I'm developing is to be used by other
> people who are also writing preprocessor code, meaning that if I choose to
> use something like BOOST_PP_SEQ_FOR_EACH internally, I'm effectively
> restricting where people can invoke my macro. IIRC, Chaos allows for all
> of
> these looping-like constructs to be used in such a manner, and I think
> that's really important for non-trivial uses of the preprocessor library.

You can still use the deferred expression(like in Chaos) to do recursive
`BOOST_PP_SEQ_FOR_EACH_I` calls. It even works in MSVC(although you may need
to
apply more scans). I showed how in a previous email here:

http://boost.2283326.n4.nabble.com/preprocessor-nested-for-each-not-working-like-expected-td4650470.html#a4650476

So in the email I write this:

    #define BOOST_PP_SEQ_FOR_EACH_R_ID() BOOST_PP_SEQ_FOR_EACH_R
    #define DEFER(x) x BOOST_PP_EMPTY()

    #define S0 (0)(1)(2)(3)
    #define S1 (5)(6)(7)(8)
    #define M4(R, DATA, ELEM) (DATA,ELEM)
    #define M2(R, DATA, ELEM) DEFER(BOOST_PP_SEQ_FOR_EACH_R_ID)()(R, M4,
ELEM, S1);
    BOOST_PP_EXPAND(BOOST_PP_SEQ_FOR_EACH_R(1, M2, ~, S0))

For your use case of allowing the user to call `BOOST_PP_SEQ_FOR_EACH_I`,
you
would instead defer the user supplied macro.

Now one difference with this is the user will now have to apply an extra
scan.
In Chaos, all the algorithms are setup in a way that `CHAOS_PP_EXPR` will
apply
the correct number of scans. For simple cases, `BOOST_PP_EXPAND` maybe
enough,
however, if the user is calling another deferred algorithm, than additional
scans will need to be applied. A simple way to solve this is to just blast
it
with a bunch of scans like this:

    #define EVAL(...) EVAL1(EVAL1(EVAL1(__VA_ARGS__)))
    #define EVAL1(...) EVAL2(EVAL2(EVAL2(__VA_ARGS__)))
    #define EVAL2(...) EVAL3(EVAL3(EVAL3(__VA_ARGS__)))
    #define EVAL3(...) EVAL4(EVAL4(EVAL4(__VA_ARGS__)))
    #define EVAL4(...) EVAL5(EVAL5(EVAL5(__VA_ARGS__)))
    #define EVAL5(...) __VA_ARGS__

This is simple, but not efficient. If you want efficient, of course, just
use
Chaos PP.

Paul Fultz II

--
View this message in context: http://boost.2283326.n4.nabble.com/BOOST-PP-array-extension-proposal-tp4679953p4680022.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk