BOOST_MPL_LIMIT_METAFUNCTION_ARITY > 8 causes compilation error on gcc

[Adam Lach <salvage@…>]

#define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
#define BOOST_MPL_LIMIT_METAFUNCTION_ARITY 9

#include <boost/mpl/lambda.hpp>

int main() {
    return 0;
}

The above code fails to compile on g++ (4.6.3 and 4.7.2 checked). Visual Compiler(VS 2010) compiles this correctly even with BOOST_MPL_LIMIT_METAFUNCTION_ARITY == 100.

See also ​http://boost.2283326.n4.nabble.com/boost-mpl-bimap-BOOST-MPL-LIMIT-METAFUNCTION-ARITY-issue-on-g-4-6-3-and-boost-1-50-td4639407.html#a4639506

[brunocodutra@…]

I found the issue to be the definition of BOOST_MPL_PP_RANGE in aux_/preprocessor/range.hpp:

#define BOOST_MPL_PP_RANGE(first, length) \
    BOOST_PP_SEQ_SUBSEQ((0)(1)(2)(3)(4)(5)(6)(7)(8)(9), first, length) \
/**/

It is hardcoded to generate a range of at most 8 elements, hence the observed issue when trying to increase BOOST_MPL_LIMIT_METAFUNCTION_ARITY past 8.

A fairly straightforward workaround is to redefine BOOST_MPL_PP_RANGE so as to generate a sequence of adequate length using boost preprocessor:

#include <boost/mpl/aux_/preprocessor/range.hpp>
#include <boost/preprocessor/enum.hpp>
#include <boost/preprocessor/tuple.hpp>
#include <boost/preprocessor/arithmetic.hpp>
#include <boost/preprocessor/punctuation.hpp>

#define COUNT(z, n, _) n

#undef BOOST_MPL_PP_RANGE
#define BOOST_MPL_PP_RANGE(first, length) \
    BOOST_PP_SEQ_SUBSEQ( \
        BOOST_PP_TUPLE_TO_SEQ( \
                BOOST_PP_ADD(first, length), \
                BOOST_PP_LPAREN() \
                BOOST_PP_ENUM(BOOST_PP_ADD(first, length), COUNT, _) \
                BOOST_PP_RPAREN() \
        ), \
        first, length \
    ) \
/**/

This compiled just fine on my setup.

3.18.5-1-ARCH #1 SMP PREEMPT Fri Jan 30 07:31:50 CET 2015
clang version 3.5.1 (tags/RELEASE_351/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

I'd be most pleased to set up a patch for this in case it is required.

[Edward Diener]

Good work but...

First your COUNT macro needs to have an absolutely distinctive name, such as BOOST_MPL_PP_RANGE_COUNT. Second you should be able to generate a seq in-place using:

#define BOOST_MPL_PP_RANGE_COUNT(z,n,_) (n)

and then in place of all that BOOST_PP_TUPLE_TO_SEQ stuff:

BOOST_PP_REPEAT(BOOST_PP_ADD(first,length),BOOST_MPL_PP_RANGE_COUNT,_)

with the appropriate adjustments to the header files.

Finally the eventual fix to MPL needs appropriate tests to make sure that the possible increase in MPL arity above 8 does indeed work in MPL in whatever situations this increase may effect.

[brunocodutra@…]

That was indeed just a tricky and dirty workaround to get it going for the end user. I've actually forked MPL and committed a cleaner version of it, which you may find on github: brunocodutra/MPL, branch Ticket7769. (I can't seem to find a way to post a link here).

I managed to get rid of COUNT, but I could not find a way to get rid of the dependence on BOOST_PP_TUPLE_TO_SEQ without being forced to define a new macro, just like you proposed yourself. I was actually concerned about defining a new name to avoid breaking some naming convention rule or anything of the sort that I might be unaware of. I would certainly be glad to hear thoughts on that though.

By the way, how should I proceed with the pull request? Should it be issued to the development branch?

Regarding testing you are absolutely right, but I must confess I have no idea on how to proceed, any advice?

[Edward Diener]

Replying to brunocodutra@…:

That was indeed just a tricky and dirty workaround to get it going for the end user. I've actually forked MPL and committed a cleaner version of it, which you may find on github: brunocodutra/MPL, branch Ticket7769. (I can't seem to find a way to post a link here).

I managed to get rid of COUNT, but I could not find a way to get rid of the dependence on BOOST_PP_TUPLE_TO_SEQ without being forced to define a new macro, just like you proposed yourself. I was actually concerned about defining a new name to avoid breaking some naming convention rule or anything of the sort that I might be unaware of. I would certainly be glad to hear thoughts on that though.

By the way, how should I proceed with the pull request? Should it be issued to the development branch?

Regarding testing you are absolutely right, but I must confess I have no idea on how to proceed, any advice?

There is nothing wrong with defining a new macro, as long as the name will be absolutely distinct. Using, as in my example, BOOST_MPL_PP_something makes it as distinct as you will need. Just check and make sure no other macro in Boost.MPL duplicates its name. In other words just make sure no other macro in Boost MPL is the same as your BOOST_MPL_PP_something macro. No outside end-user should be creating a macro even beginning with BOOST_MPL for any reason, much less BOOST_MPL_PP_.

A pull request should always be on the development branch.

As far as tests it is not absolutely required as part of the pull request, but it is always helpful. Look at the current MPL tests and try to see if there is already any one of them which tests for the manipulation of MPL arity. If so, just make sure that test still passes if the arity goes higher. If not try to develop a test of your own. If you do not understand the testing framework for Boost MPL, which probably uses either Boost.Test or Boost's lightweight test header, then do not worry further about it.