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.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:17 UTC