Re: Re: Containers for derived classes

At 00:43 2003-08-11, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> >>and they get special priority over rvalue converters.  The only way to
> >>get the behavior you want is actually to NOT hold A objects by A_ptr:
> >>
> >>     class<A>("A", init<int>() )
> >>        ...
> >>
> >>so that the rvalue converter that gets registered can be found.
> >>
> >>Clearly, we need special rules for shared_ptr, so that this won't
> >>happen.  I'm just not sure whether we need special rules for all
> >>smart pointer types, yet.  Any thoughts?
> >
> > I don't think any other smart pointer types need this special
> > handling,
>
>I guess none that I know of do (today), but it doesn't seem
>implausible that they might.  Anyway, speculation is a waste of time,
>isn't it?

Yeah it is..

> > although I guess it could simply be solved more generally by
> > introducing a real priority value for converters.
>
>Yeah, though that sounds like more generality than we need.

Maybe, but we might need something with a little finer granularity than
"in the front" or "in the back" anyway.

> > IIRC boost.python already has a specialization for C++ -> Python
> > conversions of shared_ptr's, so introducing one for Python -> C++
> > would also solve this right?
>
>Yes.

But could this possibly interfere with other converters, like implicit
conversions?

BTW. What's the motivation for holding objects by shared_ptr<..>?
Doesn't the conversions to/from shared_ptr invalidate the use of
the holder?

---
Daniel Wallin



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01