Compilation fails with many arguments, with default values

[Christopher A. Mejia <camejia@…>]

Hi, I'm using pyplusplus and Boost.Python to wrap a class where one of the member functions has many (28) arguments, most of them with default values. The wrapping code handles the default arguments with the Py++ "do nothing" approach, i.e. not by using the BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro. I am using bjam to build my project, and am confident that the code produced by Py++ should compile, because the other member functions with similar (but fewer) arguments and default arguments compile fine. I did have to increase BOOST_PYTHON_MAX_ARITY, and I am sure it is large enough to cover my arguments. I suspect I am running into a compiler limitation because I get a slightly different error message when I remove the -ftemplate-depth-128 flag (the error message appears to be truncated when I have the -ftemplate-depth-18 flag). Here is the essence of the error message, without the -ftemplate-depth-128 flag:

---

/data/cmejia/install/boost_1_39_0/boost/python/detail/invoke.hpp: In function `PyObject* boost::python::detail::invoke(... /data/cmejia/install/boost_1_39_0/boost/python/detail/caller.hpp:223: instantiated from `PyObject* ... /data/cmejia/install/boost_1_39_0/boost/python/object/py_function.hpp:38: instantiated from `PyObject* ... dcs.cpp:9: instantiated from here /data/cmejia/install/boost_1_39_0/boost/python/detail/invoke.hpp:75: error: must use .* or ->* to call pointer-to-member function in `f (...)'

---

Which doesn't make sense because none of the other code has needed to use .* or ->*. The last 19 arguments to this member function are all doubles, all with default values. If I remove the last 3 doubles from the wrapping code produced by pyplusplus, *and* remove them from the header file I am trying to wrap, I am able to compile successfully. (If I remove them only from my wrapping code, but not from the header file I am trying to wrap, I am unable to compile.) Anyway, this seems to indicate that the compiler is running up against some limit, and I was wondering if there was a flag to set to get past this problem. The current set of compiler flags, from bjam, are "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC -DBOOST_PYTHON_MAX_ARITY=40 I am using g++ version 3.4.6 on Red Hat Enterprise Linux WS release 4 (Nahant Update 6). Any information would be appreciated. (follow up...):

I developed a minimal complete test case exhibiting this problem, contained in the attached files. The compilation command I used was:

g++ -DBOOST_PYTHON_MAX_ARITY=40 -I/data/cmejia/install/boost_1_39_0 -I/data/include/python2.6

-c -o foo.o foo.cpp

As I explained earlier in the first message of this thread, this fails to compile, but if I remove one double argument towards the end (i.e. edit out one line of foo.hpp and two lines of foo.cpp) it does compile successfully. The file foo.pp is the preprocessed source from "g++ ... -E foo.cpp > foo.pp". I would appreciate any further insight into this problem, and hopefully we can use this test case to make Boost.Python an even better tool.

[Steven Watanabe]

The problem appears to be that boost::is_member_function_pointer has a hard coded limit of 24 arguments.

[troy d. straszheim]

What do we do here? Looks like type traits is at 'fault'... I'm inclined to wontfix.

[troy d. straszheim]

Here's a workaround:

​http://gitorious.org/~straszheim/boost/straszheim/commit/02776bcf430aa1dd6325c564965bca2a3c11f358

[Dave Abrahams]

Hi Troy,

Although I think 24 is a reasonable upper bound, and I very much appreciate you posting a workaround, I am wondering if your recent cleanups caused this? A potential downside of re-using other boost components is that we have to adopt their limits.

[troy d. straszheim]

None of my cleanups are in SVN... they couldn't have caused your error. As Steven points out the 'problem' is in type_traits.