← Back to team overview

dolfin team mailing list archive

  1. dolfin team
  2. Mailing list archive
  3. Message #08461

Re: Ownership

  Thread Previous • Date Previous • • Thread Next 


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 <gnw20@xxxxxxxxx>:

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
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev

References

  Thread Previous • Date Previous • • Thread Next