[C++-sig] shared_ptr converters

[Nicodemus]

David Abrahams wrote:

>Nicodemus <nicodemus at globalite.com.br> writes:
>
>  
>
>>David Abrahams wrote:
>>
>>    
>>
>>>Nicodemus <nicodemus at globalite.com.br> writes:
>>>
>>>
>>>      
>>>
>>>>David Abrahams wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>Nicodemus <nicodemus at globalite.com.br> writes:
>>>>>However, there is one significant difference: if you don't specify
>>>>>shared_ptr<Y> then you will not be able to pass a Python X object as a
>>>>>shared_ptr<Y>& argument.  Among other things that means you will not
>>>>>be able to expose member functions of the shared_ptr as methods of the
>>>>>wrapped X (see Raoul Gough's recent postings about proxies).  You will
>>>>>still be able to pass a Python X object as shared_ptr<X>,
>>>>>shared_ptr<Y>, shared_ptr<X> const&, or shared_ptr<Y> const&.
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>You mean that a function that receives a shared_ptr<X>& wouldn't work?
>>>>Because the following does:
>>>>
>>>>int Test(boost::shared_ptr<A>& a)
>>>>{
>>>>   return a->f();
>>>>}          >>> from test import *
>>>>        
>>>>
>>>>>>>a = New()
>>>>>>>Test(a)
>>>>>>>              
>>>>>>>
>>>>1
>>>>
>>>>Or am I misunderstood your response?
>>>>        
>>>>
>>>Yes, my response was badly-phrased.  I should've said: if you don't
>>>specify shared_ptr<X>, you won't be able to pass an X object
>>>_constructed from Python_ to a function expecting shared_ptr<X>&:
>>>
>>>            >>> a = A()
>>>            >>> Test(a)
>>>            Traceback...
>>>
>>>      
>>>
>>I see... then that solution doesn't solve this more common case (at
>>least more common than trying to use shared_ptr's with virtual wrappers,
>>as in my original post). 
>>    
>>
>
>Do you really think it's so common?
>
>    int Test1(boost::shared_ptr<A> a)
>    {
>        return a->f();
>    }
>
>    int Test2(boost::shared_ptr<A> const& a)
>    {
>        return a->f();
>    }
>
>    >>> from test import *
>    >>> Test1(A()) # OK
>    >>> Test2(A()) # OK
>    >>> Test(A())  # Oops
>    Traceback ...
>
>It's pretty unusal, IMO, to pass shared_ptr by *non-const* reference.
>  
>

Sorry, I meant being able to create the class on the Python side and
pass it to functions that accept shared_ptr, but I didn't realize that
you can do it, except if the function receives by non-const reference.
That is certainly unusual, like you said. Sorry about the confusion.

>>I believe that reverting Pyste back to specify the shared_ptr as
>>holder for class_ is the better thing to do for now.  What do you
>>think Dave? Thanks for helping!
>>    
>>
>
>I'm not convinced.
>

Sorry again for the confusion, you're right.

To resume, pyste is generating the following code when the user requests
shared_ptr support for a class X:

    // Temporary code for smart pointers
    objects::class_value_wrapper<
      boost::shared_ptr< X >, objects::make_ptr_instance<
        X, objects::pointer_holder<
          boost::shared_ptr< X >, X >
      >
    >();


Thanks again for the help David,
Nicodemus.