Re: [pygccxml-development] Registration order issue

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

On 8/31/06, Allen Bierbaum <al...@vr...> wrote:
> I think I just ran into a bug in registration ordering.
>
> I am using a library with it's own smart pointer hierarchy.  I have a
> class that is being registered.  One of the methods exposed by that
> class takes a default argument.  The type of that argument is a smart
> ptr to an instance of the same class.  The default value used with it is
> a const global variable of a type that is convertible to that type but
> represents a NULL smart ptr.
>
> So something like this:
>
> template <class T> FCPtr;
> typedef FCPtr<Image> ImagePtr;
> class NullFieldContainerPtr;
> const NullFieldContainerPtr  NullFC;
>
> --- method -----
>
>  { //::osg::Image::createMipmap
>
>             typedef bool ( ::osg::Image::*createMipmap_function_type )(
> ::osg::Int32,::osg::ImagePtr ) ;
>
>             Image_exposer.def(
>                 "createMipmap"
>                 , createMipmap_function_type( &::osg::Image::createMipmap )
>                 , ( ::boost::python::arg("level")=(int)(-1),
> ::boost::python::arg("destination")=osg::NullFC )
>                 , ::boost::python::default_call_policies() );
> }
>
> The problem is that the registration ordering method doesn't seem to
> know that the wrapper for the NullFieldContainerPtr needs to be
> registered before this default argument can be registered. (notice: the
> type of destination is osg::ImagePtr which has an implicit conversion
> method ,ie. constructor, that allows it to be filled from a
> NullFieldContainerPtr)
>
> Any ideas?

Yes. First of all this is the problem with boost.python library. I am
trying to solve
it, but it will take some time.

Second, you are going to be a tester of new feature I just added:
createMipmap.use_overload_macro = True

Take a look on generated code. I am sure this will work for you.

> -Allen



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