on Mon Nov 10 2008, Gennadiy Rozental wrote:
> Simple scenario:
>
> class IObject {};
>
> class Base : public IObject {
> public:
>virtual void foo() {}
> };
>
> class Derived : public Base {
>virtual void foo() {}
> };
>
> Both IObject and Base are exported into Python:
>
> bp::class_(
on Mon Nov 10 2008, Paul Melis wrote:
> The FAQ entry on this doesn't really help, so perhaps I'm not using the
> return policy
> correctly or missing something else. The full test code (which is actually
> quite
> small) is attached.
Please reduce it to its absolute minimum. Remove every si
Hans Meine informatik.uni-hamburg.de> writes:
>
> On Monday 10 November 2008 08:56:14 Gennadiy Rozental wrote:
> > It can be resolved with additional export for class Derived:
> >
> > bp::class_,noncopyable>
> > ( "Derived", bp::no_init );
> >
> > In which case above print statement starts
>
Patrick Atambo gmail.com> writes:
>
>
> I'd say you have 2 options depending
>
> Containment. This would require an API class that you export to Python with
methods that call your implementation and it's my favorite since from here you
can control what is used when calling your implementat
David Abrahams wrote:
> on Sat Nov 01 2008, Paul Melis wrote:
>
>
>> Gustavo Carneiro wrote:
>>
>>> There's an interesting question about whether it's better to use
>>> boost.python or SWIG. I've been using boost.python for years, so I
>>> have a lot invested in it, but if I we
On Monday 10 November 2008 08:56:14 Gennadiy Rozental wrote:
> It can be resolved with additional export for class Derived:
>
> bp::class_,noncopyable>( "Derived", bp::no_init );
>
> In which case above print statement starts to show mymodule.Derived.
AFAICS that's the proper solution.
> But I
>
I'd say you have 2 options depending
1. Containment. This would require an API class that you export to Python
with methods that call your implementation and it's my favorite since from
here you can control what is used when calling your implementation
methods/objects.
2. Use Pr
