[C++-sig] Re: How to expose virtual function with defaultarguments in boost.python ?

Baptiste Lepilleur gaiacrtn at free.fr
Tue Dec 7 22:47:49 CET 2004


----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Tuesday, December 07, 2004 12:11 AM
Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
in boost.python ?


> Baptiste Lepilleur wrote:
> > ----- Original Message ----- 
> > From: "David Abrahams" <dave at boost-consulting.com>
> > To: <c++-sig at python.org>
> > Sent: Monday, December 06, 2004 3:11 PM
> > Subject: [C++-sig] Re: How to expose virtual function with
defaultarguments
> > in boost.python ?
> >
> >
> >
> >>Baptiste Lepilleur wrote:
> >>
> >>>----- Original Message ----- 
> >>>From: "David Abrahams" <dave at boost-consulting.com>
> >>
> >>
> >>>>1. Use new-style polymorphism.
> >>
> >>[...]
>
> Why not just
>
>                return call< const Ogre::String& >( f.ptr());

>
> ??
>
> >         return Ogre::BillboardSet::getMaterialName();
> >     }
> > ---
> >
> > Do you have any idea on how to "remove" this warning?
>
> The warning is a compiler bug; I reported it late in the vc7.1 release
> cycle and they were not inclined to fix it.


I changed the generator to generate the "vc6/7 work-around" code. I wanted
to see if there was a difference, and there is ! There should definitely be
a note about this warning in either the tutorial or the reference
documentation.

It worries me that such a serious warning is bugged. It's one of a few that
I really look out for. By the way, how do you manage to return a reference
on something that is temporary (return value of the python function call) ?
I'm curious...

[...]

> > By the way, what is the "right" way to retrieve the PyObject* associated
to
> > the wrapper ? The only thing I found is:
> > boost::python::detail::wrapper_base_::get_owner(). Seems to be hidden
too
> > deeply to be of legal use.
>
> I didn't want to publish it until I was sure someone needed it.  Why do
> you want it?

Forget this, was just trying to find some work-around assuming the warning
was "real".

Well, I finally got pyogre binding to compile (fixed most generator bug I
introduced).

I just have one last issue remaining. It concerns the binding of *protected*
virtual function with default parameters.

Take the following code excerpt:

---
struct Ogre_SceneManager_Wrapper: Ogre::SceneManager
                                , wrapper< Ogre::SceneManager > {
//...
    void renderSingleObject(
               Ogre::Renderable* p0,
               Ogre::Pass* p1,
               bool p2,
               const Ogre::LightList* p3) {
        if (override f = this->get_override("renderSingleObject"))
            call< void >( f.ptr(), p0, p1, p2, p3);
        Ogre::SceneManager::renderSingleObject(p0, p1, p2, p3);
    }

    static void default_renderSingleObject_3(
                  Ogre::SceneManager &self,
                  Ogre::Renderable* p0,
                  Ogre::Pass* p1,
                  bool p2) {
        self.renderSingleObject(p0, p1, p2);        // <<<= problem there
    }

    void default_renderSingleObject(
                Ogre::Renderable* p0,
                Ogre::Pass* p1,
                bool p2,
                const Ogre::LightList* p3) {
        Ogre::SceneManager::renderSingleObject(p0, p1, p2, p3);
    }
};
---

The virtual member function renderSingleObject is defined has protected in
the wrapped class Ogre::SceneManager. This means that we can't call the base
class member function using "self.". I'm not aware of any tricks to work
around this, do you know any ?

Baptiste.




More information about the Cplusplus-sig mailing list