>
> Aleksandar Donev said:
> > routine DOUBLE RHS(I), for INTEGER I. Why on earth would someone make the
> > routine this way, instead of explicitly passing this function as an EXTERNAL
> > argument?
>
> I think it's just poor design. There may be extenuating circumstances
> (the original machine might have been very slow with dummy procedures, or
> the author might not have known about or liked dummy procedures), but
> most likely just a design mistake. These things happen (and are more
> obvious in retrospect than at the original time).
I think there could be other reasons why this was not because of a
poor design. For instance, if the routine DHS() is evaluated zillion
levels below user callable interfaces, it would not be practical to pass
the routine as an argument. A reasonable design could be
call set_RHS(myRHS)
call whatever()
call unset_RHS()
except that was not possible in FORTRAN.
Similarly, should one change all COMMOM/MODULE variables to dummy
arguments? It is often not a simple issue. When a design decision
is reached to define a variable as a COMMON block or MODULE variable,
or a routine not EXTERNAL, the assumption is, there is only a single
instance of this variable or this routine in the entire program. If
this assumption is not true, the design is a bad design. If the
assumption is true, the design is "good-enough". If the assumption was
true, but is no longer so, it is a tough luck.
I believe that developers still have the very same design decision issue
with Fortran 90 today.
Cheers,
Jing
>
> > My problem is that I always put functions in a MODULE, and in this case I
> > can not do that because the module functions have a different name in the
> > object file than a non-module procedure would. So I am just wondering where
> > this design comes from and if there is any F90 way to handle it.
>
> There is nothing non-F90 about it. The badness has not increased by moving
> to F90, just conserved. You can
> (a) rewrite the code to pass dummy procedures around instead of using RHS
> or
> (b) write a function that is not in a module.
>
> Not much else you can do, really.
>
> Cheers,
> --
> ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
> ([log in to unmask])
>
> _____________________________________________________________________
> This message has been checked for all known viruses by Star Internet delivered
> through the MessageLabs Virus Control Centre. For further information visit
> http://www.star.net.uk/stats.asp
>
--
________________________________ _-__-_-_ _-___---
Jing Guo, [log in to unmask], (301)614-6172(o), (301)614-6297(fx)
Data Assimilation Office, Code 910.3, NASA/GSFC, Greenbelt, MD 20771
|