Re: [Boost-bugs] [Boost C++ Libraries] #7769: BOOST_MPL_LIMIT_METAFUNCTION_ARITY > 8 causes compilation error on gcc

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #7769: BOOST_MPL_LIMIT_METAFUNCTION_ARITY > 8 causes compilation error on gcc
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2015-02-08 23:30:37

#7769: BOOST_MPL_LIMIT_METAFUNCTION_ARITY > 8 causes compilation error on gcc
------------------------------------+---------------------------------
  Reporter:  Adam Lach <salvage@…>  |      Owner:  agurtovoy
      Type:  Bugs                   |     Status:  new
 Milestone:  To Be Determined       |  Component:  mpl
   Version:  Boost 1.52.0           |   Severity:  Problem
Resolution:                         |   Keywords:  arity, metafunction
------------------------------------+---------------------------------

Comment (by eldiener):

 Replying to [comment:3 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/7769#comment:4>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.