dolfin team mailing list archive

[Joachim Berdal Haga <jobh@xxxxxxxxx>]

On 26 January 2012 22:40, Anders Logg <logg@xxxxxxxxx> wrote:
> On Wed, Jan 25, 2012 at 03:21:12PM +0100, Joachim Berdal Haga wrote:
>> This seems to be because of the instantiation of boost::shared_arrays.
>> The ownership of the array data is not transferred (the data will be
>> deleted by the caller of evaluate()), so this does not really add any
>> safety.
>>
>> I don't have a complete picture of how Array<> is used, does the
>> Python layer rely on the shared semantics (in other places)? If not,
>> it might be better to make them non-shared and create copies for use
>> in Python where needed.
>
> Would it help if we do this:
>
> 1. Make GenericFunction::evaluate an inline function that just calls
>   a new version of GenericFunction::eval.
>
> 2. The new version of GenericFunction::eval has the same
>   implementation as the current evaluate() function.
>
> The result would be that we get two eval() functions, one with plain
> pointers and one with Array(). A C++ user (and the JIT-compiled
> expressions) would use the plain pointer version, while the Array
> version gets wrapped for Python subclassing (where I assume the extra
> cost will not make a difference).

I'm unsure about the details of how much of the call tree would have
to get dual signatures, but I guess it would be possible. However, it
doesn't add any safety for the Python layer because the data will be
deleted by the C++ layer even if Python holds a (shared) reference.
And as Johan says, the different interfaces are a maintenance problem.

In my opinion, it would be best to make Array<T> a simple T*/len
container, and either subclass it or add a flag to decide if it owns
the data. Then, for sharing, use shared_ptr<Array>, and add some
safeguards that the shared_ptr actually holds an owned array.

-j.