← Back to team overview

dolfin team mailing list archive

Re: [HG DOLFIN] Move code from Function copy?constructor to assignment operator and

 

On Mon, Feb 16, 2009 at 11:30:46AM +0000, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Mon, Feb 16, 2009 at 11:52:54AM +0100, Johan Hake wrote:
> >> On Monday 16 February 2009 11:31:36 Anders Logg wrote:
> >>> On Mon, Feb 16, 2009 at 10:12:21AM +0000, Garth N. Wells wrote:
> >>>> Anders Logg wrote:
> >>>>> On Mon, Feb 16, 2009 at 10:36:52AM +0100, Johan Hake wrote:
> >>>>>> On Sunday 15 February 2009 21:23:44 DOLFIN wrote:
> >>>>>>> One or more new changesets pushed to the primary dolfin repository.
> >>>>>>> A short summary of the last three changesets is included below.
> >>>>>>>
> >>>>>>> changeset:   5701:d3661203791d9c7707695c59adbbd3a2e20a220c
> >>>>>>> tag:         tip
> >>>>>>> user:        Anders Logg <logg@xxxxxxxxx>
> >>>>>>> date:        Sun Feb 15 21:23:36 2009 +0100
> >>>>>>> files:       dolfin/function/Function.cpp
> >>>>>>> description:
> >>>>>>> Move code from Function copy constructor to assignment operator and
> >>>>>>> call assignment operator from copy constructor
> >>>>>> I liked Garth solution better.
> >>>>>>
> >>>>>>  1) A copy constructor that, just copies the Function if it has
> >>>>>>     a FunctionSpace.
> >>>>>>  2) The assignment operator works only for discrete Functions.
> >>>>>>
> >>>>>> We could add an interpolate() (or something) function that
> >>>>>>
> >>>>>>   v.interpolate(*_vector, *_function_space);
> >>>>> We already have exactly such a function.
> >> Do we?
> > 
> > Yes:
> > 
> >   /// Interpolate function to given function space
> >   void interpolate(GenericVector& coefficients, const FunctionSpace& V) const;
> > 
> >>>>>> Then the user can explicitly create a discrete function of its
> >>>>>> user-defined Function. Now the user gets this as an implicitly result
> >>>>>> of a function copy, which make litle sense to me.
> >>>>>>
> >>>>>> But that's just me :)
> >>>>> I like it. Other opinions?
> >>>> It is neat, but I would prefer any interpolation to be more explicit so
> >>>> that it's clear what's going on. A copy should be a straight copy.
> >>>>
> >>>> Garth
> >>> ok. I've changed it back. See if it looks ok.
> >> Now a user cannot copy a Function that is not a discrete function, which was 
> >> the case before we started all this. 
> > 
> > Wasn't that the point? It's not possible to copy the eval() operator.
> > 
> 
> It is if a MyFunction object is copied to a MyFunction object, which we 
> couldn't do before. My change made this possible.
> 
> Garth

What's the point of that? It's like copying half a Function.

If I do

  v = w;

I expect v to be in everything essential the same as w.

-- 
Anders


> > Well it is but then it would be necessary to keep a pointer to the
> > given Function and propagate the eval call to that Function's eval.
> > That seems a bit overkill.
> > 
> >> Also sometimes a copy is something different than an assignment, so it is not 
> >> always meaningfull to use *this = other; in the copy constructor.
> > 
> > I've found it's almost always the case that one can implement the
> > copy constructor by
> > 
> >   *this = other;
> > 
> > We use this in a bunch of other places, including the Mesh class.
> > 
> > In which cases will it break?
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature


Follow ups

References