pygccxml-development

[pygccxml-development] binding of a default argument calling a function

[Benoit L. <ben...@mo...>]

Hello,

In a class, I have the following method:
void addLayer( boost::shared_ptr<Color> color = Color::create(1,1,1) );

This method is exposed by py++ with the following incorrect code:
ClassWrapper_exposer.def(
 "addLayer",
 addLayer_function_type( &::MyClass::addLayer ),
 bp::arg("color")=Color::create(float, float, float)(1.0e+0f, 1.0e+0f) );
                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
note the (float..) part which is incorrect, and only 2 parameters are supplied then

Rright now i have to edit the code generated by py++...or maybe I can try to use the following code:

boost::shared_ptr<Color> defaultColor() { return Color::create(1,1,1); }
void addLayer( boost::shared_ptr<Color> color = defaultColor() );

Is it a known bug in py++?

Thanks!

Re: [pygccxml-development] binding of a default argument calling a function

[Roman Y. <rom...@gm...>]

On Mon, Jun 28, 2010 at 1:22 PM, Benoit Leveau
<ben...@mo...> wrote:
> Hello,
>
> In a class, I have the following method:
> void addLayer( boost::shared_ptr<Color> color = Color::create(1,1,1) );
>
> This method is exposed by py++ with the following incorrect code:
> ClassWrapper_exposer.def(
> "addLayer",
> addLayer_function_type( &::MyClass::addLayer ),
> bp::arg("color")=Color::create(float, float, float)(1.0e+0f, 1.0e+0f) );
>                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> note the (float..) part which is incorrect, and only 2 parameters are
> supplied then
>
> Rright now i have to edit the code generated by py++...or maybe I can try to
> use the following code:
>
> boost::shared_ptr<Color> defaultColor() { return Color::create(1,1,1); }
> void addLayer( boost::shared_ptr<Color> color = defaultColor() );
>
> Is it a known bug in py++?

Yes. basically this is a limitation of the technology, py++ is built
on - gccxml : http://language-binding.net/pygccxml/upgrade_issues.html?highlight=default#free-and-member-function-default-arguments

GCCXML is not able to dump any/arbitrary C++ expression. You can find
a lot of post on this subject in GCCXML mailing list. pygccxml/py++
tries pretty hard to fix this behavior, but there are cases where it
fails.

The work-around is pretty simple:

#f is "calldef_t" instance
for arg in f.arguments:
    arg.default_value = "<<<new default value or None>>>"


thus you will not have to touch generated code.

HTH
-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] binding of a default argument calling a function

[Benoit L. <ben...@mo...>]

Roman Yakovenko wrote:
> On Mon, Jun 28, 2010 at 1:22 PM, Benoit Leveau
> <ben...@mo...> wrote:
>> Hello,
>>
>> In a class, I have the following method:
>> void addLayer( boost::shared_ptr<Color> color = Color::create(1,1,1) );
>>
>> This method is exposed by py++ with the following incorrect code:
>> ClassWrapper_exposer.def(
>> "addLayer",
>> addLayer_function_type( &::MyClass::addLayer ),
>> bp::arg("color")=Color::create(float, float, float)(1.0e+0f, 1.0e+0f) );
>>                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> note the (float..) part which is incorrect, and only 2 parameters are
>> supplied then
>>
>> Rright now i have to edit the code generated by py++...or maybe I can try to
>> use the following code:
>>
>> boost::shared_ptr<Color> defaultColor() { return Color::create(1,1,1); }
>> void addLayer( boost::shared_ptr<Color> color = defaultColor() );
>>
>> Is it a known bug in py++?
> 
> Yes. basically this is a limitation of the technology, py++ is built
> on - gccxml : http://language-binding.net/pygccxml/upgrade_issues.html?highlight=default#free-and-member-function-default-arguments
> GCCXML is not able to dump any/arbitrary C++ expression. You can find
> a lot of post on this subject in GCCXML mailing list. pygccxml/py++
> tries pretty hard to fix this behavior, but there are cases where it
> fails.
Thanks!
I don't know why I didn't find this page :(
and I didn't think about searching specifically in the gccxml mailing list...
 
> The work-around is pretty simple:
> 
> #f is "calldef_t" instance
> for arg in f.arguments:
>     arg.default_value = "<<<new default value or None>>>"
> 
> thus you will not have to touch generated code.
> 

Works great thanks.
Benoit