dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #12145
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