Pyste: bug: overriding overloaded virtual functions.
Hi, One more bug. Consider an overloaded virtual function that is implemented in the base class and not overridden in the derived class. // --------- overload.hpp -------- namespace test { class Base { public: virtual void f() {} virtual void f(const int i){} }; class A : public Base { public: void f(){} }; } // --------- overload.hpp -------- Running Pyste on this produces this wrapper code: // ---------- wrapper code ---------- struct test_A_Wrapper: test::A { [...] void f(const int p0) { call_method< void >(self, "f", p0); } void default_f(const int p0) { test::A::f(p0); // <<=========== ERROR. test::Base::f(p0); // <<=========== Should be this. } [...] // ---------- wrapper code ---------- Attached is a patch (two lines) for the _current_ CVS code that fixes this. cheers, prabhu
Hi Prabhu, Prabhu Ramachandran wrote:
Hi,
One more bug. Consider an overloaded virtual function that is implemented in the base class and not overridden in the derived class.
// --------- overload.hpp -------- namespace test { class Base { public: virtual void f() {} virtual void f(const int i){} };
class A : public Base { public: void f(){} }; } // --------- overload.hpp --------
Running Pyste on this produces this wrapper code:
// ---------- wrapper code ---------- struct test_A_Wrapper: test::A { [...] void f(const int p0) { call_method< void >(self, "f", p0); }
void default_f(const int p0) { test::A::f(p0); // <<=========== ERROR. test::Base::f(p0); // <<=========== Should be this. } [...] // ---------- wrapper code ----------
Attached is a patch (two lines) for the _current_ CVS code that fixes this.
I just applied your patch. I really appreciate your effort in finding this problems, thanks a lot! Regards, Nicodemus.
"N" == nicodemus <nicodemus@globalite.com.br> writes:
N> I just applied your patch. I really appreciate your effort in N> finding this problems, thanks a lot! No problem. I also tried solving the problem where Pyste was not generating wrapper code for virtual operators. Unfortunately the code was a little too complex and I was not able to generate a patch. I thought I had to re-order some of the function definitions (move ExportOperators above ExportVirtualFunctions etc.) and did not want to go that far. Is this also fixed in CVS? Thanks! cheers, prabhu
Prabhu Ramachandran wrote:
"N" == nicodemus <nicodemus@globalite.com.br> writes:
N> I just applied your patch. I really appreciate your effort in N> finding this problems, thanks a lot!
No problem. I also tried solving the problem where Pyste was not generating wrapper code for virtual operators. Unfortunately the code was a little too complex and I was not able to generate a patch. I thought I had to re-order some of the function definitions (move ExportOperators above ExportVirtualFunctions etc.) and did not want to go that far. Is this also fixed in CVS?
No, not yet. I think I will change the way operators are currently exported. Currently, it tries to use Boost.Python's facilities for operators, ie: struct A { A operator+(const B); } It will generate: class_<A>(...) .def(self + other<B>()) ; But I will change it to export the explicit Python special names, to ease dealing with virtual operators: class<A>(...) .def("__add__", &A::operator+) ; You people think that this is a great loss in readability? Because this would let my code in the operators section much more clear. Regards, Nicodemus.
"N" == nicodemus <nicodemus@globalite.com.br> writes:
[virtual operators bug] N> But I will change it to export the explicit Python special N> names, to ease dealing with virtual operators: N> class<A>(...) N> .def("__add__", &A::operator+) N> ; N> You people think that this is a great loss in readability? I'm OK with the above since it reads quite naturally to *me*. I'm not sure what others will feel though. cheers, prabhu
participants (2)
-
Nicodemus -
Prabhu Ramachandran