On 26 January 2012 22:40, Anders Logg <l...@simula.no> 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. _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
