[C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached)

[Neal Becker]

Ravi wrote:

> On Thursday 02 October 2008 20:03:58 Neal Becker wrote:
>> ublas::vector<double> create (int size, double init) {
>> return ublas::vector<double> (size, init);
>> }
>>
>> With default return value policy, this fails.    We used:
>> register_vector_to_python_converters< false, contiguous_vector_to_py,
>> default_ublas_array_traits>();
>>
>> Which does _not_ copy the data and uses PyArray_SimpleNewFromData.  The
>> data is immediately destroyed and the array returned to python is
>> garbage.
> 
> You are right; I was wrong in my previous reply. I need the help of a
> boost.python expert to tell me what to do in this case. For the default
> return value policy, we end up in registry_to_python_value<T>::operator(),
> but the last line of that function is never called. Why this is, I have
> been unable to figure out.
> 
>> It would be nice if the function could return a shared_ptr, which python
>> would manage.  This doesn't seem to work:
>>
>> boost::shared_ptr<ublas::vector<double> > create (int size, double init)
>> { boost::shared_ptr<ublas::vector<double> > u (new ublas::vector<double>
>> (size, init)); return u;
>> }
> 
> This, too, remains a puzzle to me. Do shared_ptr conversions not work for
> objects with custom to_python converters?
> 

I realize now, this isn't a problem of boost::python.  The problem is the design of numpy.  numpy can adopt external storage, but has no way to really manage it.  It _could_ use the C 'free' function on it, and although that _might_ work, it can't do the 'right' thing, which is call your choice of deallocation function (like boost::shared_ptr could, for example).