dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Apr 24, 2008 at 10:08:25AM +0200, Dag Lindbo wrote:
> Anders Logg wrote:
> > On Wed, Apr 23, 2008 at 11:24:33PM +0200, Martin Sandve Alnæs wrote:
> >> Dag recently discussed issues with object ownership in the context of
> >> Vector and DiscreteFunction. Are there any existing general
> >> conventions for this in DOLFIN? It's not easy to know which function
> >> arguments will be kept references to, which will be assumed ownership
> >> of and later deleted, and which return value pointers you yourself
> >> should assume ownership of.
> >>
> >> In the absense of reference counting, the least we should do is agree
> >> on some conventions to make this easier, and be very careful to
> >> document this next to each relevant function. However, doing this
> >> requires some overview of many parts of the code, so it's not quickly
> >> done. I guess this should be thought of during the Function cleanup?
> > 
> > As a first rule, we never assume responsibility for data given as
> > pointers/references. So if you do
> > 
> >   Foo foo(mesh);
> > 
> > then that means foo needs to have access to the mesh but does not
> > assume responsibility for deleting it.
> > 
> > Then there are exceptions to this rule. For example, when doing
> > 
> >   Function u = w[0];
> >   Function p = w[1];
> > 
> > Here u and p will be responsible for their own vectors since no one
> > explicitly creates those vectors.
> > 
> > Then there's also the recent exception Dag added.
> > 
> > In general, I think we should let C++ be C++, which means I don't
> > think it's a good idea to use smart pointers everywhere.
> > 
> 
> Are there other classes that have the property of DiscreteFunction that 
> they may or may not be responsible for freeing the pointers they contain?

Yes, in DirichletBC:

  // Sub domain markers (if any)
  MeshFunction<uint>* sub_domains;

  // True if sub domain markers are created locally
  bool sub_domains_local;

There may be a few others.

> I agree with Martin that these are fragile sections of code that warrant 
> careful documentation. In addition, I would suggest _strong_ 
> encapsulation (no friendship). E.g., it seems safest that a 
> DiscreteFunction knows whether it will own dof data or not when it is 
> constructed, and not let any other object manipulate this property later.
>
> The patch I submitted (Anders, will you accept it?) for LinearPDE is not 
> in line with this (I would prefer in the future that the 
> constructor/init of DiscreteFunction initializes the proper vector and 
> assumes ownership of it).

It's been there for a while:

  http://www.fenics.org/hg/dolfin?cs=9dce699d4b90

-- 
Anders