[C++-sig] Re: call_method

[Brett Calcott]

>
> >> Now /that's/ starting to sound intriguing.  I wonder if it's possible
> >> to derive our U class from boost::python::objects::instance<>, and
> >> automatically generate shared_ptr<> converters for it.
> >>
> >> Maybe the whole idea of holding a shared_ptr<U> is bogus from the
get-go.
> >>
> >
> > I'm not sure what it buys you either. If I have to derive the U
> > class from boost::python::objects::instance<> then I have already
> > given away non-intrusiveness.
>
> Which really doesn't matter at all because the U class is
> purpose-built.

The immediate advantage of the shared_ptr is that it is entirely external -
you can use it on objects without changing the source. I thought this was
the main advantage -- but as you point out below, there are others...

>
> > Are there some other advantages to using shared_ptr?
>
> Oh, yes: many, many. For example, shared_ptr<U> -> shared_ptr<T> is a
> legitimate conversion, even though you haven't intruded on U. And
> probably more-importantly, shared_ptr<> interoperates seamlessly in
> many contexts and serves as a "one-stop shop" for nearly all smart
> pointer needs. Just see the enclosed document for reasons why.
>
>

Wow - mind-expanding material. But I still cannot see a way to using
shared_ptr. The customer release function passed in the constructor doesn't
give you enough control to do the "crazy" counting stuff.
How did you want to progress this? Is it worth trying to put something like
this back into the library -- or should it just go into the documentation as
a "technique"?

Cheers,

Brett