[C++-sig] g++ compiler limitations other than -ftemplate-depth-n and -DBOOST_PYTHON_MAX_ARITY ?

[Christopher A Mejia]

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

----- Original Message ----- 
From: Stefan Seefeld
To: Development of Python/C++ integration
Sent: Monday, June 08, 2009 7:39 AM
Subject: Re: [C++-sig] g++ compiler limitations other 
than -ftemplate-depth-n and -DBOOST_PYTHON_MAX_ARITY ?


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.

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.

>   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
tracker.

Regards,
       Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at 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 at python.org; 
from=seefeld at 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 ?) 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: foo.hpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090611/aaacc843/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: foo.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090611/aaacc843/attachment.txt>