From a.huebl at hzdr.de Mon Feb 2 19:43:15 2015 From: a.huebl at hzdr.de (Huebl, Axel) Date: Mon, 02 Feb 2015 19:43:15 +0100 Subject: [C++-sig] Boost.Python: Review of Patches In-Reply-To: <54C8F06A.9080508@hzdr.de> References: <54C8EBB7.60902@hzdr.de> <54C8F06A.9080508@hzdr.de> Message-ID: <54CFC543.3080301@hzdr.de> Hm, the language binding is dead and 404 http://sourceforge.net/p/boost/mailman/boost-langbinding/ Has anyone an idea about my question? :) Best, Axel On 28.01.2015 15:21, Huebl, Axel wrote: > Oh I just realized > boost-langbinding > > is the better place to report this. > > Sry for cross-posting, I will migrate my question there. > > > Best, > Axel > > On 28.01.2015 15:01, Huebl, Axel wrote: >> Hi, >> >> I was directed here from the Boost groups homepage >> http://www.boost.org/community/groups.html#cplussig >> >> so I hope my question is well placed. >> >> I was wondering if, how and when patches for Boost.Python (specially bug >> fixes) are merged. >> >> When I reported two bugs (including patches) beginning of the month >> (that sounds a bit impatient - so if I am just pushing to much just tell >> me) in both trac and on GitHub: >> https://svn.boost.org/trac/boost/ticket/10932 >> https://svn.boost.org/trac/boost/ticket/10933 >> >> I noticed that there are other pull requests since at least two boost >> stable releases on GitHub >> https://github.com/boostorg/python/pulls >> (some of them also with a trac issue) >> >> that have not yet been reviewed/included/commented-on/closed in the code >> base even if they are most of the time straight forward fixes. >> >> My background: >> I am combined Boost.Python with via cmake with an open source, (mpi) >> parallel, many-GPGPU code [1] compiled with nvcc 6.5 and noted some >> minor compile errors in Boost.Python that can be fixed quite easily. >> >> (Btw: it works like a charm, thank you so much!) >> >> >> Best regards, >> Axel Huebl >> >> [1] http://picongpu.hzdr.de >> > > > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > https://mail.python.org/mailman/listinfo/cplusplus-sig > -- Axel Huebl Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5099 bytes Desc: S/MIME Cryptographic Signature URL: From stefan at seefeld.name Mon Feb 2 19:49:02 2015 From: stefan at seefeld.name (Stefan Seefeld) Date: Mon, 02 Feb 2015 13:49:02 -0500 Subject: [C++-sig] Boost.Python: Review of Patches In-Reply-To: <54CFC543.3080301@hzdr.de> References: <54C8EBB7.60902@hzdr.de> <54C8F06A.9080508@hzdr.de> <54CFC543.3080301@hzdr.de> Message-ID: <54CFC69E.3070807@seefeld.name> Axel, I'm trying to look into the open patches to see whether I can help shrink the list of open issues. The issues / patches I have seen from you all look minor / sensible, so I hope I can merge them soon. Still trying to get back up-to-speed with the boost build and test processes etc. I'm subscribed to both the c++-sig as well as the boost mailing lists. I think the former might be slightly better to discuss boost.python issues, if only for the higher SNR. FWIW, Stefan On 02/02/15 01:43 PM, Huebl, Axel wrote: > Hm, the language binding is dead and 404 > http://sourceforge.net/p/boost/mailman/boost-langbinding/ > > Has anyone an idea about my question? :) > > Best, > Axel > On 28.01.2015 15:21, Huebl, Axel wrote: >> Oh I just realized >> boost-langbinding >> >> is the better place to report this. >> >> Sry for cross-posting, I will migrate my question there. >> >> >> Best, >> Axel >> >> On 28.01.2015 15:01, Huebl, Axel wrote: >>> Hi, >>> >>> I was directed here from the Boost groups homepage >>> http://www.boost.org/community/groups.html#cplussig >>> >>> so I hope my question is well placed. >>> >>> I was wondering if, how and when patches for Boost.Python (specially bug >>> fixes) are merged. >>> >>> When I reported two bugs (including patches) beginning of the month >>> (that sounds a bit impatient - so if I am just pushing to much just tell >>> me) in both trac and on GitHub: >>> https://svn.boost.org/trac/boost/ticket/10932 >>> https://svn.boost.org/trac/boost/ticket/10933 >>> >>> I noticed that there are other pull requests since at least two boost >>> stable releases on GitHub >>> https://github.com/boostorg/python/pulls >>> (some of them also with a trac issue) >>> >>> that have not yet been reviewed/included/commented-on/closed in the code >>> base even if they are most of the time straight forward fixes. >>> >>> My background: >>> I am combined Boost.Python with via cmake with an open source, (mpi) >>> parallel, many-GPGPU code [1] compiled with nvcc 6.5 and noted some >>> minor compile errors in Boost.Python that can be fixed quite easily. >>> >>> (Btw: it works like a charm, thank you so much!) >>> >>> >>> Best regards, >>> Axel Huebl >>> >>> [1] http://picongpu.hzdr.de >>> >> >> >> _______________________________________________ >> Cplusplus-sig mailing list >> Cplusplus-sig at python.org >> https://mail.python.org/mailman/listinfo/cplusplus-sig >> > > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > https://mail.python.org/mailman/listinfo/cplusplus-sig -- ...ich hab' noch einen Koffer in Berlin... From ullrich.koethe at iwr.uni-heidelberg.de Tue Feb 3 19:25:45 2015 From: ullrich.koethe at iwr.uni-heidelberg.de (Ullrich Koethe) Date: Tue, 03 Feb 2015 19:25:45 +0100 Subject: [C++-sig] Boost.Python: Review of Patches In-Reply-To: <54CFC69E.3070807@seefeld.name> References: <54C8EBB7.60902@hzdr.de> <54C8F06A.9080508@hzdr.de> <54CFC543.3080301@hzdr.de> <54CFC69E.3070807@seefeld.name> Message-ID: <54D112A9.5080400@iwr.uni-heidelberg.de> Hi Stefan, I've also been waiting for someone to look at my pull request https://github.com/boostorg/python/pull/8 (well, I may be too patient). It would be really nice if something would eventually happen. Best regards Ulli Am 02.02.2015 um 19:49 schrieb Stefan Seefeld: > Axel, > > I'm trying to look into the open patches to see whether I can help > shrink the list of open issues. The issues / patches I have seen from > you all look minor / sensible, so I hope I can merge them soon. Still > trying to get back up-to-speed with the boost build and test processes etc. > > I'm subscribed to both the c++-sig as well as the boost mailing lists. I > think the former might be slightly better to discuss boost.python > issues, if only for the higher SNR. > > FWIW, > Stefan > > On 02/02/15 01:43 PM, Huebl, Axel wrote: >> Hm, the language binding is dead and 404 >> http://sourceforge.net/p/boost/mailman/boost-langbinding/ >> >> Has anyone an idea about my question? :) >> >> Best, >> Axel >> On 28.01.2015 15:21, Huebl, Axel wrote: >>> Oh I just realized >>> boost-langbinding >>> >>> is the better place to report this. >>> >>> Sry for cross-posting, I will migrate my question there. >>> >>> >>> Best, >>> Axel >>> >>> On 28.01.2015 15:01, Huebl, Axel wrote: >>>> Hi, >>>> >>>> I was directed here from the Boost groups homepage >>>> http://www.boost.org/community/groups.html#cplussig >>>> >>>> so I hope my question is well placed. >>>> >>>> I was wondering if, how and when patches for Boost.Python (specially bug >>>> fixes) are merged. >>>> >>>> When I reported two bugs (including patches) beginning of the month >>>> (that sounds a bit impatient - so if I am just pushing to much just tell >>>> me) in both trac and on GitHub: >>>> https://svn.boost.org/trac/boost/ticket/10932 >>>> https://svn.boost.org/trac/boost/ticket/10933 >>>> >>>> I noticed that there are other pull requests since at least two boost >>>> stable releases on GitHub >>>> https://github.com/boostorg/python/pulls >>>> (some of them also with a trac issue) >>>> >>>> that have not yet been reviewed/included/commented-on/closed in the code >>>> base even if they are most of the time straight forward fixes. >>>> >>>> My background: >>>> I am combined Boost.Python with via cmake with an open source, (mpi) >>>> parallel, many-GPGPU code [1] compiled with nvcc 6.5 and noted some >>>> minor compile errors in Boost.Python that can be fixed quite easily. >>>> >>>> (Btw: it works like a charm, thank you so much!) >>>> >>>> >>>> Best regards, >>>> Axel Huebl >>>> >>>> [1] http://picongpu.hzdr.de >>>> >>> >>> >>> _______________________________________________ >>> Cplusplus-sig mailing list >>> Cplusplus-sig at python.org >>> https://mail.python.org/mailman/listinfo/cplusplus-sig >>> >> >> >> _______________________________________________ >> Cplusplus-sig mailing list >> Cplusplus-sig at python.org >> https://mail.python.org/mailman/listinfo/cplusplus-sig > > From a.huebl at hzdr.de Thu Feb 12 11:20:05 2015 From: a.huebl at hzdr.de (Huebl, Axel) Date: Thu, 12 Feb 2015 11:20:05 +0100 Subject: [C++-sig] Boost.Python: Review of Patches In-Reply-To: <54D112A9.5080400@iwr.uni-heidelberg.de> References: <54C8EBB7.60902@hzdr.de> <54C8F06A.9080508@hzdr.de> <54CFC543.3080301@hzdr.de> <54CFC69E.3070807@seefeld.name> <54D112A9.5080400@iwr.uni-heidelberg.de> Message-ID: <54DC7E55.1030204@hzdr.de> Stefan, thank you for taking the time, that is fantastic. Did you already take a look at the reports? Thanks, Axel On 03.02.2015 19:25, Ullrich Koethe wrote: > Hi Stefan, > > I've also been waiting for someone to look at my pull request > https://github.com/boostorg/python/pull/8 > (well, I may be too patient). It would be really nice if something would > eventually happen. > > Best regards > Ulli > > Am 02.02.2015 um 19:49 schrieb Stefan Seefeld: >> Axel, >> >> I'm trying to look into the open patches to see whether I can help >> shrink the list of open issues. The issues / patches I have seen from >> you all look minor / sensible, so I hope I can merge them soon. Still >> trying to get back up-to-speed with the boost build and test processes >> etc. >> >> I'm subscribed to both the c++-sig as well as the boost mailing lists. I >> think the former might be slightly better to discuss boost.python >> issues, if only for the higher SNR. >> >> FWIW, >> Stefan >> >> On 02/02/15 01:43 PM, Huebl, Axel wrote: >>> Hm, the language binding is dead and 404 >>> http://sourceforge.net/p/boost/mailman/boost-langbinding/ >>> >>> Has anyone an idea about my question? :) >>> >>> Best, >>> Axel >>> On 28.01.2015 15:21, Huebl, Axel wrote: >>>> Oh I just realized >>>> boost-langbinding >>>> >>>> is the better place to report this. >>>> >>>> Sry for cross-posting, I will migrate my question there. >>>> >>>> >>>> Best, >>>> Axel >>>> >>>> On 28.01.2015 15:01, Huebl, Axel wrote: >>>>> Hi, >>>>> >>>>> I was directed here from the Boost groups homepage >>>>> http://www.boost.org/community/groups.html#cplussig >>>>> >>>>> so I hope my question is well placed. >>>>> >>>>> I was wondering if, how and when patches for Boost.Python >>>>> (specially bug >>>>> fixes) are merged. >>>>> >>>>> When I reported two bugs (including patches) beginning of the month >>>>> (that sounds a bit impatient - so if I am just pushing to much just >>>>> tell >>>>> me) in both trac and on GitHub: >>>>> https://svn.boost.org/trac/boost/ticket/10932 >>>>> https://svn.boost.org/trac/boost/ticket/10933 >>>>> >>>>> I noticed that there are other pull requests since at least two boost >>>>> stable releases on GitHub >>>>> https://github.com/boostorg/python/pulls >>>>> (some of them also with a trac issue) >>>>> >>>>> that have not yet been reviewed/included/commented-on/closed in the >>>>> code >>>>> base even if they are most of the time straight forward fixes. >>>>> >>>>> My background: >>>>> I am combined Boost.Python with via cmake with an open source, >>>>> (mpi) >>>>> parallel, many-GPGPU code [1] compiled with nvcc 6.5 and noted some >>>>> minor compile errors in Boost.Python that can be fixed quite easily. >>>>> >>>>> (Btw: it works like a charm, thank you so much!) >>>>> >>>>> >>>>> Best regards, >>>>> Axel Huebl >>>>> >>>>> [1] http://picongpu.hzdr.de >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Cplusplus-sig mailing list >>>> Cplusplus-sig at python.org >>>> https://mail.python.org/mailman/listinfo/cplusplus-sig >>>> >>> >>> >>> _______________________________________________ >>> Cplusplus-sig mailing list >>> Cplusplus-sig at python.org >>> https://mail.python.org/mailman/listinfo/cplusplus-sig >> >> > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > https://mail.python.org/mailman/listinfo/cplusplus-sig > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5099 bytes Desc: S/MIME Cryptographic Signature URL: From cpo at slac.stanford.edu Wed Feb 18 23:13:46 2015 From: cpo at slac.stanford.edu (Christopher O'Grady) Date: Wed, 18 Feb 2015 14:13:46 -0800 (PST) Subject: [C++-sig] passing by non-const reference? Message-ID: <20150218221346.8491D15F@rhel6-64k.slac.stanford.edu> Hi, Based on websearches we have done, we believe that boost-python does not allow passing arguments by non-const-reference (at least, not easily). Can someone confirm this is still the case, or point me to some documentation that discusses it? We think this prevents us from return multiple arguments from a method call. Looking through the mailing list archives, we believe this is impossible. If someone knows differently can you let us know? Thanks! chris From stefan at seefeld.name Thu Feb 19 14:23:36 2015 From: stefan at seefeld.name (Stefan Seefeld) Date: Thu, 19 Feb 2015 08:23:36 -0500 Subject: [C++-sig] passing by non-const reference? In-Reply-To: <20150218221346.8491D15F@rhel6-64k.slac.stanford.edu> References: <20150218221346.8491D15F@rhel6-64k.slac.stanford.edu> Message-ID: <54E5E3D8.6090307@seefeld.name> On 18/02/15 05:13 PM, Christopher O'Grady wrote: > Hi, > > Based on websearches we have done, we believe that boost-python does > not allow passing arguments by non-const-reference (at least, not > easily). Can someone confirm this is still the case, or point me to > some documentation that discusses it? We think this prevents us from > return multiple arguments from a method call. > > Looking through the mailing list archives, we believe this is > impossible. If someone knows differently can you let us know? If I understand your question, you aren't so much asking about const vs. non-const arguments, but rather passing by value vs. passing by reference. Whenever I want to return multiple values, I write a wrapper function that packs the return values into a tuple, making the interface more pythonic. For example: void func(int input, int &out1, int &out2); tuple pyfunc(int input) { int out1, out2; func(input, out1, out2); return make_tuple(out1, out2); } ... and then wrap pyfunc instead of func. Does this address the problem you are trying to solve ? Stefan -- ...ich hab' noch einen Koffer in Berlin... From talljimbo at gmail.com Thu Feb 19 14:25:30 2015 From: talljimbo at gmail.com (Jim Bosch) Date: Thu, 19 Feb 2015 08:25:30 -0500 Subject: [C++-sig] passing by non-const reference? In-Reply-To: <20150218221346.8491D15F@rhel6-64k.slac.stanford.edu> References: <20150218221346.8491D15F@rhel6-64k.slac.stanford.edu> Message-ID: On Wed, Feb 18, 2015 at 5:13 PM, Christopher O'Grady wrote: > > Hi, > > Based on websearches we have done, we believe that boost-python does > not allow passing arguments by non-const-reference (at least, not > easily). Can someone confirm this is still the case, or point me to > some documentation that discusses it? We think this prevents us from > return multiple arguments from a method call. > > Looking through the mailing list archives, we believe this is > impossible. If someone knows differently can you let us know? > > Passing Boost.Python-wrapped C++ classes wrapped by non-const-reference works just fine. What doesn't work is passing immutable Python primitive types by non-const-reference (e.g. numeric types, str). The reason is that Python itself doesn't support output arguments, so it's actually impossible to change the value of, say, an integer, when it's passed to a wrapped function, and the assumption is that any C++ function that takes a non-const-reference does indeed intend to modify that argument, and hence that shouldn't be allowed. Note that this is a Python limitation, not a Boost.Python one - any wrapper generator library will have a problem with this case, though it may not be the same problem. While Boost.Python refuses to wrap such code, others may allow it but generate incorrect wrappers that don't modify the output argument in Python. The solution is to modify these interfaces to return output arguments in a tuple, as in the example Stefan just provided. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From CBotos at aer.com Fri Feb 20 16:29:24 2015 From: CBotos at aer.com (Botos, Christopher) Date: Fri, 20 Feb 2015 15:29:24 +0000 Subject: [C++-sig] Wrapping virtual method returning void Message-ID: <7C9F40129AEA5B49A87082A93198BF300928CE1B@VRSKUTMB2.veriskdom.com> I have an example C++ base class (Song) with a virtual method (chorus) returning void that is called by another method (play) of the same class. I want to be able to derive a python class from this and override the virtual method. I experience the following behavior: 1. If I simply instantiate the wrapped base class in python and call play, **the virtual chorus is never entered/executed**. 2. If I create a derived class and override the virtual chorus, the derived chorus is executed correctly. 3. If I change the base class chorus to return int (or anything) instead of void, the base class chorus is executed correctly. I have wrapped my class as described here: http://www.boost.org/doc/libs/1_43_0/libs/python/doc/v2/wrapper.html My example C++, python code, and output python output is below (I've tried to make it as concise as possible). I can work around this issue in my application by having my virtual method return an unused object, although this is not ideal. I would appreciate any other suggestions, whether I'm doing something incorrectly, or is this possibly a boost python bug? //------------------------------------------------ // Has virtual method returning void // Numbers indicate order in which the print statements should appear. //------------------------------------------------ class Song { public: virtual ~Song(){} void play() { std::cout << "\n1) Base class --> Song.play" << std::endl; chorus(); std::cout << "3) Base class <-- Song.play" << std::endl; } // THIS METHOD IS NEVER EXECUTED virtual void chorus() { std::cout << "2) Base class Song.chorus returning void" << std::endl; } }; struct SongWrapper : Song, bp::wrapper { void chorus() { if (bp::override chorus = this->get_override("chorus")) chorus(); return; Song::chorus(); return; } void default_chorus() { this->Song::chorus(); } }; //------------------------------------------------ // Has virtual method returning int // Numbers indicate order in which the print statements should appear. //------------------------------------------------ class AnotherSong { public: virtual ~AnotherSong(){} void play() { std::cout << "\n1) Base class --> AnotherSong.play" << std::endl; chorus(); std::cout << "3) Base class <--AnotherSong.play" << std::endl; } // THIS METHOD (returning int) IS EXECUTED virtual int chorus() { std::cout << "2) Base class AnotherSong.chorus returning int" << std::endl; return 0; } }; struct AnotherSongWrapper : AnotherSong, bp::wrapper { int chorus() { if (bp::override chorus = this->get_override("chorus")) return chorus(); return AnotherSong::chorus(); } int default_chorus() { return this->AnotherSong::chorus(); } }; BOOST_PYTHON_MODULE(Songs) { bp::class_("Song") .def("play", &Song::play) .def("chorus", &Song::chorus, &SongWrapper::default_chorus) ; bp::class_("AnotherSong") .def("play", &AnotherSong::play) .def("chorus", &AnotherSong::chorus, &AnotherSongWrapper::default_chorus) ; } #------------------------------------------------ # Python file ... #------------------------------------------------ from Songs import Song, AnotherSong # Base class chorus returning void is not executed: step 2 is missing in the output s1 = Song() s1.play() # Derived class chorus is executed: step 2 in the output class Chart(Song): def chorus(self): print "** 2) Derived class Chart.chorus" c1 = Chart() c1.play() # Base class chorus returning int is executed: step 2 in output s2 = AnotherSong() s2.play() #------------------------------------------------ # Python output ... # In first case, step 2 is missing ... chorus was not executed #------------------------------------------------ 1) Base class --> Song.play 3) Base class <-- Song.play 1) Base class --> Song.play ** 2) Derived class Chart.chorus 3) Base class <-- Song.play 1) Base class --> AnotherSong.play 2) Base class AnotherSong.chorus returning int 3) Base class <--AnotherSong.play ________________________________ This email is intended solely for the recipient. It may contain privileged, proprietary or confidential information or material. If you are not the intended recipient, please delete this email and any attachments and notify the sender of the error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Holger.Joukl at LBBW.de Mon Feb 23 08:52:49 2015 From: Holger.Joukl at LBBW.de (Holger Joukl) Date: Mon, 23 Feb 2015 08:52:49 +0100 Subject: [C++-sig] Wrapping virtual method returning void In-Reply-To: <7C9F40129AEA5B49A87082A93198BF300928CE1B@VRSKUTMB2.veriskdom.com> References: <7C9F40129AEA5B49A87082A93198BF300928CE1B@VRSKUTMB2.veriskdom.com> Message-ID: Hi, not boost.python- but C/C++ syntax-related. You never reach the Base class call in your wrapper class: > struct SongWrapper : Song, bp::wrapper > { > void chorus() > { > if (bp::override chorus = this->get_override("chorus")) > chorus(); > return; <------------ Called unconditionally > Song::chorus(); > return; > } > > void default_chorus() { this->Song::chorus(); } > }; I suggest using proper {} brackets and indentation with if-else constructs for readability. Your int-returning member function doesn't suffer from this problem: > > struct AnotherSongWrapper : AnotherSong, bp::wrapper > { > int chorus() > { > if (bp::override chorus = this->get_override("chorus")) > return chorus(); > return AnotherSong::chorus(); > } > > int default_chorus() { return this->AnotherSong::chorus(); } > }; Holger Landesbank Baden-Wuerttemberg Anstalt des oeffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704 Amtsgericht Stuttgart From CBotos at aer.com Mon Feb 23 20:35:56 2015 From: CBotos at aer.com (Botos, Christopher) Date: Mon, 23 Feb 2015 19:35:56 +0000 Subject: [C++-sig] Cplusplus-sig Digest, Vol 76, Issue 6 In-Reply-To: References: Message-ID: <7C9F40129AEA5B49A87082A93198BF30092962ED@VRSKUTMB2.veriskdom.com> Well, I'm embarrassed. I don't believe I did that. Thanks so much! ________________________________________ From: Cplusplus-sig [cplusplus-sig-bounces+cbotos=aer.com at python.org] on behalf of cplusplus-sig-request at python.org [cplusplus-sig-request at python.org] Sent: Monday, February 23, 2015 6:00 AM To: cplusplus-sig at python.org Subject: Cplusplus-sig Digest, Vol 76, Issue 6 Send Cplusplus-sig mailing list submissions to cplusplus-sig at python.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.python.org/mailman/listinfo/cplusplus-sig or, via email, send a message with subject or body 'help' to cplusplus-sig-request at python.org You can reach the person managing the list at cplusplus-sig-owner at python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Cplusplus-sig digest..." Today's Topics: 1. Re: Wrapping virtual method returning void (Holger Joukl) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 Feb 2015 08:52:49 +0100 From: Holger Joukl To: Development of Python/C++ integration Subject: Re: [C++-sig] Wrapping virtual method returning void Message-ID: Content-Type: text/plain; charset=US-ASCII Hi, not boost.python- but C/C++ syntax-related. You never reach the Base class call in your wrapper class: > struct SongWrapper : Song, bp::wrapper > { > void chorus() > { > if (bp::override chorus = this->get_override("chorus")) > chorus(); > return; <------------ Called unconditionally > Song::chorus(); > return; > } > > void default_chorus() { this->Song::chorus(); } > }; I suggest using proper {} brackets and indentation with if-else constructs for readability. Your int-returning member function doesn't suffer from this problem: > > struct AnotherSongWrapper : AnotherSong, bp::wrapper > { > int chorus() > { > if (bp::override chorus = this->get_override("chorus")) > return chorus(); > return AnotherSong::chorus(); > } > > int default_chorus() { return this->AnotherSong::chorus(); } > }; Holger Landesbank Baden-Wuerttemberg Anstalt des oeffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704 Amtsgericht Stuttgart ------------------------------ Subject: Digest Footer _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig at python.org https://mail.python.org/mailman/listinfo/cplusplus-sig ------------------------------ End of Cplusplus-sig Digest, Vol 76, Issue 6 ******************************************** ________________________________ This email is intended solely for the recipient. It may contain privileged, proprietary or confidential information or material. If you are not the intended recipient, please delete this email and any attachments and notify the sender of the error.