Anders Logg wrote:
> 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.
>
I think that the class is worth keeping and the simple change suggested
by Dag should remove the ambiguity.
Garth
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DOLFIN-dev mailing list
> [email protected]
> http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
