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/
|
