-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Arkadiy Vertleyb

Hi Paul,

...

Is there any particular reason why you need 'i' in the outer dimension? If not, regular SEQ_FOR_EACH and SEQ_FOR_EACH_I should work together:

Actually yes, I do need it -- I am generating series of typedefs, each one depending on the previous, and I need to generate names for them. I also need 'i' in the inner loop.

Okay.

My guess is, I have to use REPEAT, passing sequence as auxiliary data, and using SEQ_ELEM to access current element. This looks a little clumsier, and probably less efficient (?) than more native SEQ_FOR_EACH, but it's fine with me as long as I know that this is the best I can do in this case (REPEAT *is* reentrant, right?).

There are a variety of ways that you could do it. The first way that I thought of would be to transform the outer sequence with SEQ_FOR_EACH_I and then process the result with SEQ_FOR_EACH_I... #include <boost/preprocessor/seq/for_each.hpp> #include <boost/preprocessor/seq/for_each_i.hpp> #include <boost/preprocessor/tuple/elem.hpp> #define A(r, _, i, elem) ((i, elem)) #define B(r, _, pair) \ BOOST_PP_SEQ_FOR_EACH_I( \ C, \ BOOST_PP_TUPLE_ELEM(2, 0, pair), \ BOOST_PP_TUPLE_ELEM(2, 1, pair) \ ) \ /**/ #define C(r, i, j, elem) elem(i, j) BOOST_PP_SEQ_FOR_EACH( B, ~, BOOST_PP_SEQ_FOR_EACH_I( A, ~, ((a)(b)(c)) ((d)(e)(f)) ((g)(h)(i)) ) ) --> a(0, 0) b(0, 1) c(0, 2) d(1, 0) e(1, 1) f(1, 2) g(2, 0) h(2, 1) i(2, 2) That is probably what I'd do, and is probably more efficient than REPEAT w/SEQ_ELEM. To answer you're other question, yes, REPEAT is reentrant.

Also, do I understand correctly, that, if I wanted to wrap the call to REPEAT in yet another macro, something like SEQ_ENUM[_TRAILING](seq, macro), I would have to take care myself of this macro to be reentrant? In the simplest case, I would just have to provide two identical macros, SEQ_ENUM_0 and SEQ_ENUM_1, and use the first one outside, and the second -- inside (this would take care of one layer nesting).

Basically, yes. This is pretty much what the library has to do as well for anything reentrant (but with far more replications). I've been thinking about various ways to generalize some of this that I might be able to get away with in the pp-lib (read: ...that I might be able to implement even on typical preprocessors...). However, that might imply always doing everything automatically--meaning with automatic recursion on everything and no syntax for direct reentrance (i.e. no z, r, d, etc., state variables). Even if I take away the compiler workarounds in the pp-lib, and even if I don't use any of the "fancy" things that Chaos does, there are still some fundamental problems with the pp-lib (IMO). In particular, I don't like this exact situation where reuse of algorithms to create other algorithms creates a dependency and removing the dependency requires removing the reuse. I also don't like there being multiple states (such as z, r, and d). The main idea is to distinguish between entry point and algorithmic step. As an example, WHILE needs to be able to make many algorithmic steps, but it doesn't really need all that many entry points (i.e. is unlikely that a user would need more than, say, two or three nested invocations of WHILE). Given that, it is possible to map a small set of entry points onto a larger set of algorithmic steps. The questions are whether it is possible to implement this on buggy preprocessors (which I think it is) and whether it is worth it because it is still less than ideal.

...

(Of course, this design limitation doesn't exist in Chaos. All higher-order macros are reentrant--without implementation replication.)

But I would still have to take special care of reentrancy of my own macros, correct?

Yes, but it isn't terribly difficult. There is a difference also between recursion and arbitrary reentrancy. I.e. designing a recursive algorithm with Chaos is fairly easy, designing a higher-order recursive algorithm is slightly more difficult, but still fairly easy. Neither involve macro replication.

I actually think disallowing recursion of function-like macros is totally artificial and unjustified in the first place :-(

I agree. Not only that, but it is also the single greatest cause of inefficiency in complex macro expansion. OTOH, the lack of recursion allows some meaningful things that could not be done any other way (assuming the preprocessor is otherwise the same). Regards, Paul Mensonides