boost::python and shared_ptr

[Alex Martelli]

"John Hunter" <jdhunter at nitace.bsd.uchicago.edu> wrote in message
news:1rg0alk1x2.fsf at video.bsd.uchicago.edu...
>
> >>>>> "Alex" == Alex Martelli <aleax at aleax.it> writes:
>
>     Alex> What about adding (Python-side only maybe) another
>     Alex> 'constructor' (factory, if you will) of SomeClass that's a
>     Alex> template?  If your C++ accepts templated constructors,
>
>     Alex> class SomeClass {
>     Alex> ...
>     Alex>   template <class Derived>
>     Alex>   SomeClass(boost::shared_ptr<Derived>) {
>     Alex>     // ... whatever ...
>     Alex> }
>
> I don't think I fully understand, but I'm intrigued.  Would this be
> expected to work w/o the clone method I mentioned in the OP?  If not,

The idea would be to avoid the clone method, yes -- if this
works at all.


> I don't see the advantage of this over what I have currently:
>
>   typedef boost::shared_ptr<Base> PtrBase;
>   SomeClass( PtrBase )
>
> because the problem doesn't seem to be in the polymorphism ( I can use
> my shared_ptr<Derived> in classes expecting a shared_ptr<Base>

In this case, then such a template as I proposed probably
won't help, either -- sorry.


> But to get back to your example ... it makes me wonder if the example
> you gave, or something similar ( a constructor that knows something
> about how boost::python represents objects created in python and the
> conversion functions to_python from_python ) could be used like
>
> d = Derived()
> s = SomeClass( d )
>
> w/o the use of the clone method.  In a nutshell, how to automagically
> create a shared_ptr<Derived> from a Derived object constructed in
> python.  Is your example expected do this?

Yes, that was what I expected would happen.

> BTW: I use gcc 2.95.2.  Does it support templated constructors?

Sorry, no idea -- the newer gcc 3.0 does, though, I believe.


Alex