ffc team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/12/3 Anders Logg <logg@xxxxxxxxx>:
> On Wed, Dec 03, 2008 at 05:04:37PM +0100, Martin Sandve Alnæs wrote:
>> 2008/12/3 Garth N. Wells <gnw20@xxxxxxxxx>:
>> >
>> >
>> > Martin Sandve Alnæs wrote:
>> >>
>> >> There is a signature:
>> >>
>> >>  // Create form on given function space(s) with given coefficient(s)
>> >> (shared data)
>> >>  PoissonLinearForm(std::tr1::shared_ptr<const dolfin::FunctionSpace>
>> >> V0, dolfin::Function& w0) : dolfin::Form(), f(*this)
>> >>
>> >> but no signature where both the function spaces and functions are
>> >> shared pointers. For an application with full use of shared pointers,
>> >> we need that.
>> >>
>> >
>> > I don't think that it's required. I brought this point up a while ago,
>> >
>> >  http://www.fenics.org/pipermail/ffc-dev/2008-November/001923.html
>>
>> Quoting this:
>> """
>> On Thu, Nov 06, 2008 at 08:14:47PM +0000, Garth N. Wells wrote:
>> > For the 'shared' versions, shouldn't the coefficients also be shared
>> > pointers?
>>
>> It's not necessary since these arguments will not be stored as
>> data. They will just be assigned to the coefficients.
>> """
>>
>> That's just plain wrong. Through Coefficient::attach, the Form will
>> store shared pointers to them with NoDeleters, and these pointers
>> won't share the reference count of an eventual shared pointer I
>> have in my application.
>
> Yes, that seems to be wrong.
>
> Do you need shared_ptr only in the constructors or do you also want
> shared_ptr for the assignment operator?

An additional assignment operator would be nice.

> Is it possible to reuse the DOLFIN-wrappers from dolfinformat.py in
> FFC? It would be practical if we could reuse the same code since it's
> a bit messy to generate with all the different combinations of
> constructors with and without shared_ptr etc. It would also increase
> the chances for generating compatible code.

> Perhaps it can be placed in UFC, say under src/utils/python/dolfin?
> It could be a single function that gets the form name(s) as input, the
> list of coefficient names etc so it would be independent of the
> form-compiler.

I'm not reusing that code because it uses some ffc specific
assumptions and there are things I don't find flexible enough.
In particular, I don't want to duplicate element code.
I'll keep my code with no dependencies, and then we
can see whether we can agree on how to reuse it.

--
Martin