...

1) I think both test libraries should #error if you go over the limit.

2) Why don't we extend the limits? I may wind up doing this real quick to keep my code working (needs 71). Can I merge the changes into trunk when I'm done and after 1.48 is finished?

It took a while, but I found this thread: http://lists.boost.org/boost-users/2006/11/23285.php

I believe that for most libraries, there's a non-trivial increase in compile-time for any user of the library when you increase the arity of things. It's config switch. The library user sets BOOST_MPL_LIMIT_VECTOR_SIZE to whatever he needs and sets BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS. The silly thing is there's an undocumented limit which doesn't warn it just complains when it can't include map60.

It would be easy to have map50, just use the limit instead of a hard coded 50. That would allow someone who needs just a it to do it.

Bumping up the default could have rather adverse effects on the compile time of people who doesn't want to pay for it. No, the library is header only. If you leave the limits at 20 you'll include file10 and file20, but no more.

I've currently got the hack in my code. It only works if you do it before including any of the standard headers and it's uggly because BOOST_MPL_LIMIT_MAP_SIZE is redefined 50->70. #define ULTIMATE_N 70 #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #include #include #include namespace boost { namespace mpl { # define BOOST_PP_ITERATION_PARAMS_1 \ (3,(51, ULTIMATE_N, )) # include BOOST_PP_ITERATE() }} #define BOOST_MPL_LIMIT_MAP_SIZE ULTIMATE_N // do this for each mpl::map, mpl::list, fusion::vector, fusion::map Chris