Anders Logg wrote:
> On Thu, Jun 26, 2008 at 05:28:42PM +0100, Garth N. Wells wrote:
>>
>> Martin Sandve Alnæs wrote:
>>> 2008/6/26 Garth N. Wells <[EMAIL PROTECTED]>:
>>>> Martin Sandve Alnæs wrote:
>>>>> If we can use references somewhere we use pointers, we should change
>>>>> that. All factory functions will of course return pointers, and they
>>>>> clearly give away ownership to the caller. Where else do we need to
>>>>> use pointers?
>>>> DiscreteFunction is an example where we use a number of pointers because a
>>>> DiscreteFunction may or may not own the data. Without having a bunch of
>>>> constructors, I don't know how to tell DiscreteFunction what it does and
>>>> doesn't own.
>>>>
>>>> Pointers are also used quite a bit in DofMap and DofMapSet. These of course
>>>> will be overhauled in the near future.
>>> Ok. Also, we should allow FooVector and FooMatrix to be a "view" of an
>>> object they don't own, or take over ownership. This may be important
>>> if somebody tries to use dolfin as a component on the side and not the
>>> main application framework, e.g. if they have an existing PETSc Mat or
>>> Epetra_FEVector to use. Both are possible with shared_ptr, possibly
>>> with custom deleters in special cases.
>>>
>> I'll play around with this for the NewtonSolver to experiment as it's
>> pretty unobtrusive. At the moment NewtonSolver owns the Jacobian matrix,
>> but I'd like to set it up such that the NewtonSolver can create and own
>> the matrix (which will be the case 95% of the time), or a user can
>> supply the matrix which NewtonSolver may or may not then own. A reason
>> a user might want to supply a matrix is to specify a special matrix type
>> (say a PETSc UMFPACK matrix).
>>
>> Garth
>
> I think we should try to design the classes in such a way that we
> never need to use smart pointers. It should be obvious whether or not
> the data is owned by an object. That's not the case right now so we
> need to try harder.
>
Yes, we do need to try harder. There has been a proliferation of
pointers recently which has muddied the waters.
> For example, the following line in XMLFile.cpp is outright disturbing:
>
> ff.local_vector = x;
>
> :-)
>
Don't look further or you'll be even more disturbed :). The above line
of code comes from LinearPDE.cpp.
Garth
> It should not be the responsibility of XMLFile to set a private
> variable in Function to let Function know it owns the data (even
> if it's a friend).
>
> The correct way to read in *data for a Function* should be to
>
> 1. Assert that we get a discrete function or make the function
> discrete.
>
> 2. Extract the data from the Function (which are owned by the
> Function).
>
> 3. Read values into those data.
>
> Something like this:
>
> void XMLFile::operator>>(Function& f)
> {
> // Step 1
> dolfin_assert(f.type() == Function::discrete);
>
> // Step 2
> Mesh& mesh = f.mesh();
> GenericVector& x = f.vector();
>
> // Step 3
> file >> mesh;
> file >> x;
> }
>
> The first step could be replaced by something like
>
> f.init(Function::discrete);
>
> which could be a call to create an empty discrete Function.
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DOLFIN-dev mailing list
> [email protected]
> http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
