Fw: g++ compiler limitations other than -ftemplate-depth-n and -DBOOST_PYTHON_MAX_ARITY ?
Stefan / cplusplus-sig, Based on Stefan's encouragement, 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. 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. Thanks in advance, --Chris P.S. Unfortunately, I was unable to include preprocessed source from "g++ ... -E foo.cpp" because the result was too large for the mailing list system. Christopher A Mejia wrote:
Stefan,
Thanks for your response. The API that I am trying to wrap is the Data Client Server portion of the U.S. Naval Research Labs' SIMDIS Analysis & Display Tool (simdis.nrl.navy.mil). This is free software, but does require registration and there is a human in the loop of the approval process. Anyway, I don't feel comfortable redistributing the software (or preprocessed details), but if you're really interested you could obtain it directly yourself. Sorry, I'm not interested enough to register at this time. :-) I merely tried to be helpful in debugging the issue.
Apparently this API is a good test case for pushing some of the limits of Boost.Python. Since you agree that this is probably a compiler issue, it's unlikely that you or anyone else would be able to reproduce the same errors anyway.
I came up with a workaround, which is to wrap a version of the function without the last three arguments, i.e. from Python I am OK with always having those last three parameters set to their default values. But if anyone has any other ideas to try, I'd like to hear them. It would really be best to construct the proverbial "minimal complete test case" that allows others to reproduce the issue. You may consider writing some stand-alone test using similar calls as in your code, which you then may freely send do this list, or file as an issue to the boost
The only compiler issue I mentioned was a misleading error message. I still believe the real issue might be inside boost.python (where some code may not support your high arity, and can't be configured with BOOST_PYTHON_MAX_ARITY), but I lack details to be able to confirm this. tracker. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig The following line is added for your protection and will be used for analysis if this message is reported as spam: (Raytheon Analysis: IP=82.94.164.166; e-from=cplusplus-sig-bounces+camejia=raytheon.com@python.org; from=seefeld@sympatico.ca; date=Jun 8, 2009 2:39:33 PM; subject=Re: [C++-sig] g++ compiler limitations other than -ftemplate-depth-n and -DBOOST_PYTHON_MAX_ARITY ?)
On 06/11/2009 08:13 PM, Christopher A Mejia wrote:
Stefan / cplusplus-sig,
Based on Stefan's encouragement, I developed a minimal complete test case
Thanks ! Can you please submit that as an issue on https://svn.boost.org/trac/boost/ ? We may then follow-up there... Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan, OK--it's in the system as #3183. Thanks again for your help, and anyone should feel free to let me know if they need more information about this issue. --Chris ----- Original Message ----- From: Stefan Seefeld To: Development of Python/C++ integration Sent: Monday, June 15, 2009 3:00 PM Subject: Re: [C++-sig] Fw: g++ compiler limitations otherthan -ftemplate-depth-n and -DBOOST_PYTHON_MAX_ARITY ? On 06/11/2009 08:13 PM, Christopher A Mejia wrote:
Stefan / cplusplus-sig,
Based on Stefan's encouragement, I developed a minimal complete test case
Thanks ! Can you please submit that as an issue on https://svn.boost.org/trac/boost/ ? We may then follow-up there... Stefan -- ...ich hab' noch einen Koffer in Berlin...
Christopher A Mejia wrote:
Stefan,
OK--it's in the system as #3183. Thanks again for your help, and anyone should feel free to let me know if they need more information about this issue.
--Chris
Hey Chris, Steven Watanabe points out that this is due to a hardcoded limit of 24 arguments in type_traits' is_member_function_pointer. I've put a test that demonstrates a workaround on my python branch: http://gitorious.org/~straszheim/boost/straszheim/commit/02776bcf430aa1dd632... Which will make its way back up to svn at some point. I don't really think there is a good argument for increasing the arity of type_traits for this case, so I'm going to close the ticket. Get back to me with any questions... -t
participants (3)
-
Christopher A Mejia -
Stefan Seefeld -
troy d. straszheim