Re: [Boost-bugs] [Boost C++ Libraries] #4523: fix for #4501

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #4523: fix for #4501
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-09-19 18:14:33

#4523: fix for #4501
  Reporter: ookami1@… | Owner: no-maintainer
      Type: Patches | Status: new
 Milestone: Boost 1.44.0 | Component: preprocessor
   Version: Boost 1.44.0 | Severity: Problem
Resolution: | Keywords:

Comment (by ookami1@…):

 The following patch allows BOOST_PP_FOR to run up to 256 iterations, one
 more than 1.44 code does. This extension is nessecary to make a couple of
 macros in preprocessor/seq expand successfully on sequences of maximum
 length, and it brings BOOST_PP_FOR in line with BOOST_PP_LIMIT_FOR
 indicating 256 successful iterations.

 In a loop of n iterations, you need n loop control checks for each
 iteration, and one final extra check to exit the loop. This last extra
 check is not always provided for in the 1.44 BOOST_PP_FOR implementation.
 If the loop count reaches 256, the maximum allowed, the 257-th cycle
 expansion unconditionally results in an error, and, thus, omits the final

 The idea here is to run into an error only, if a final check indicates
 continuation of the loop. As a consequence, the 257-th loop cycle
 BOOST_PP_FOR_257 becomes a meaningful entry point into the loop, which in
 turn requires an extension of BOOST_PP_AUTO_REC. The previous patch does
 the nessecary modifications, and needs to be applied as well.

 It would have had been nice, if indexing of loop iterations had started
 with 0, so reserving the range 0 - 255 for successful iterations. It would
 have meant, all indices were from the preprocessor integer range and would
 have appeared in natural order. Unfortunately, it was once decided to
 start with 1, and meanwhile there is code out there, that relies on this

 In order to not break outside code, I decided to leave the indexing as is,
 i.e running from 1 to 256, then index 257 assigned to the ultimate final
 check cycle, and index 0 reserved for the unconditionally failing error

 The proposed changes here should not affect code that runs successfully
 under 1.44 code, as it extends BOOST_PP_FOR only. Code triggering errors
 in BOOST_PP_FOR is likely to see different behavior, as previously failing
 loops may now succeed, and error indices have been moved. I was unable to
 locate an instance inside Boost itself, where this hurts.

 The following code fails under the current 1.44 implementation, but will
 run successfully after having the patches applied:

 #include <boost/preprocessor.hpp>

 #define P(r, s) s
 #define O(r, s) BOOST_PP_DEC(s)
 #define M(r, s) (s)
 char const a[] = BOOST_PP_STRINGIZE(BOOST_PP_FOR(256, P, O, M));

 int main()
         printf("%s", a);
         return 0;


 Wolf Lammen

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:04 UTC