dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Apr 21, 2011 at 04:47:05PM +0100, Garth N. Wells wrote:
> Having just looked at the VariationalProblem class, there is
> considerable duplication of functions that return objects (there being a
> reference and a shared_ptr version). I suggest that we use shared_ptr
> versions, unless there is a special reason to use a reference, and
> remove the reference versions (throughout the code). Reasons for this are:
>
> 1) Less code
>
> 2) shared_ptrs are now handled seamlessly by SWIG
>
> 3) shared_ptr versions are safer
>
> 4) These member functions are usually called from other parts of the
> library, and developers at that level should be comfortable with
> shared_ptrs.
>
> I can imagine that we may in a limited number of cases want a reference
> version to keep the user interface clean.

I'm not sure. If we want to keep the reference versions in a few
places, then it's more consistent to always have foo() and
foo_shared_ptr().

But maybe those exceptions are very few? For example, a user will
most likely not call V.mesh() since the user already has access to the
mesh.

I grepped for data access in the C++ demos and found only the following:

  mesh.topology()
  mesh.geometry()
  function.vector()

In addition we have mesh.data().

I also found one child_shared_ptr() which is a bit ugly.

So yes, I think we should remove the reference versions with the above
exceptions.

--
Anders