dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jun 23, 2008 at 02:51:05PM +0200, Dag Lindbo wrote:
> Anders Logg wrote:
> > On Thu, Jun 19, 2008 at 11:41:52PM +0200, Dag Lindbo wrote:
> >> Hello again!
> >>
> >> Here comes another suggestion about the DOLFIN public interface:
> >>
> >> Constructing time dependent functions by subclassing from Function and
> >> TimeDependent is very very nice. The way u.sync(t) works by storing a
> >> pointer to t is also very clever. However, I think it is too clever --
> >> most would expect pass-by-value semantics when passing a scalar to a
> >> function. A very simple change could make it a lot clearer what's going
> >> on: Pass a pointer to t instead of a constant reference. This forces the
> >> user to take the address of the scalar, which really shows what's going
> >> on. E.g.
> >>
> >> u.sync(&t)
> >>
> >> Today I misunderstood the reference nature of sync(t), and wrote code like
> >> this:
> >>
> >> while(t < T){
> >>   "compute timestep"
> >>   t += dt
> >>   sync_bc(t)
> >> }
> >>
> >> void sync_bc(real t){
> >>   for "all Dirichlet BCs"
> >>      bc.sync(t)  // Pointer to stack memory gets assigned!!!!
> >> }
> >>
> >> :-( Of course, no one would be foolish enough to pass a pointer to stack
> >> memory knowingly in such a short lived context.
> >>
> >> /Dag
> > 
> > TimeDependent does not seem to be used anywhere in the code so now
> > it's just a fancy way of storing the current time. Objects that want
> > to store the current time could equally well just add a member
> > 
> >   real t;
> > 
> > I suggest we remove TimeDependent for now and add it back later when
> > we find any use for it.
> > 
> > ok?
> 
> No! It is really good feature for non-kernel applications.
> I think there is a clear benefit for users to have this base class to
> standardize things. It is one of only a handful situations where I
> really like multiple inheritance!
> 
> /Dag

I understand, but since the interface is not used in DOLFIN, it's
difficult to make any sense of how the class should behave.

The current implementation is bound to cause trouble (as you have
noticed) and I don't know how to fix it since I don't know how the
class is used.

-- 
Anders

Attachment: signature.asc
Description: Digital signature