[preprocessor] automatic recursion curiosity

Hello all, I have a curiosity about an implementation detail of Boost.Preprocessor: How does the lib implement Automatic Recursion?
From the docs under Topic > Reentrancy > Automatic Recursion: http://www.boost.org/doc/libs/1_51_0/libs/preprocessor/doc/index.html
`` Using automatic recursion to reenter various sets of macros is obviously much simpler. It completely hides the underlying implementation details. So, if it is so much easier to use, why do the state parameters still exist? The reason is simple as well. When state parameters are used, the state is known at all times. This is not the case when automatic recursion is used. The automatic recursion mechanism has to deduce the state at each point that it is used. This implies a cost in macro complexity that in some situations--notably at deep macro depths--will slow some preprocessors to a crawl. '' I have not looked at the source code and I'm looking for the glory details. However, I'd like to understand at a high level how Boost.Preprocessor is able to implement Automatic Recursion behind the scene (it just bothers me not being able to imagine how this is actually done and why it is expensive on some preprocessors). Can anyone provide a quick explanation or point me to some email thread / docs that explain that? Thanks a lot! --Lorenzo

AMDG On 09/14/2012 09:24 AM, Lorenzo Caminiti wrote:
Hello all,
I have a curiosity about an implementation detail of Boost.Preprocessor: How does the lib implement Automatic Recursion?
<snip>
It looks something like this: #define TEST_BOOST_PP_REPEAT_1(n, macro, data) 0 #define TEST_OKAY(z, n, data) 1 // expands to 1 if we BOOST_PP_REPEAT_1 is available BOOST_PP_CAT(TEST_, BOOST_PP_REPEAT_1(1, OKAY, ~)) There's some extra magic around this using BOOST_PP_AUTO_REC to find the smallest available dimension. In Christ, Steven Watanabe
participants (2)
-
Lorenzo Caminiti
-
Steven Watanabe