[C++-sig] Re: pyste: current cvs/1_30_00 difference in treatment of overloaded members

David Abrahams dave at boost-consulting.com
Thu May 15 13:38:18 CEST 2003


Nicodemus <nicodemus at globalite.com.br> writes:

> Paul Rudin wrote:
>
>>Hi,
>>
>>I've noticed a difference between the c++ generated by the current cvs and the 1_30_00 released version.
>>Here's an illustration:
>>
>
> Thanks for the report Rubin! I found the problem, but now a doubt came
> up about how to properly export protected (and even private) methods.
>
> Suppose:
>
> class A
> {
> public:
>     const char* get_name() { return name(); }
>
> protected:
>     virtual const char* name() { return "foo"; }
> };
>  Here's the wrapper generated by pyste now:
>
>
> struct A_Wrapper: A
> {
>     A_Wrapper(PyObject* self_, const A & p0):
>         A(p0), self(self_) {}
>
>     A_Wrapper(PyObject* self_):
>         A(), self(self_) {}
>
>     const char * name() {
>         return call_method< const char * >(self, "name");
>     }
>
>     PyObject* self;
> };
>
>
> BOOST_PYTHON_MODULE(test)
> {
>     class_< A, A_Wrapper >("A", init<  >())
>         .def(init< const A & >())
>         .def("get_name", &A::get_name)
>     ;
>
> }
>
>
> Now from Python:
>
>  >>> from test import *
>  >>> a = A()
>  >>> a.get_name()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> AttributeError: 'A' object has no attribute 'name'
>  >>>
>
> Sure: get_name is called in C++, which calls the *overriden* "name" in
> A_Wrapper, but the Python object doesn't have this function. Even
> thought the protected method "name" has a default implementation, this
> is not passed to Boost.Python at all. It couldn't be declared like any
> public virtual function in the class_ definition (hence passsing also
> its default implementation), because A::name is protected and can't be
> accessed by outside code. 

So? It can be accessed from A_Wrapper, where you need to declare the
default implementation.

> So how to export default implementations of
> protected virtual methods?

I don't see the problem.

Private virtual functions are a bigger problem; the best you can do
is to break the C++ rules by replicating the base class declaration
with the private function declared protected.

HTH,
Dave
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com





More information about the Cplusplus-sig mailing list