Fortran 90 with its MODULEs and USE has made one to think more hardly
about the question when should the names of things be unique?
Obviously, this is not a problem for standalone code, but is when other
MODULEs are USEd, one links against object libraries etc. This is also
related to the issue of the best `MODULE strategy'.
Unique variables and routine names? Surely not. These are either
visible to other routines or not. If not, no worry (nice feature, this
data hiding). If they are, then one can rename them in the USE
statement; I think this difficulty is more than offset by the ease of
having understandable code without long,
guaranteed-to-be-unique-in-the-entire-world names.
The names of object files (one per file, not per routine or MODULE)?
Probably a good idea. Presumably, they would be unique anyway within an
object library, but often one links against more than one object
library.
The names of MODULEs? Definitely. Is it not the name which is the only
means of deciding which module to use? If they are not unique, then one
has to think about the order in which include directories are searched,
which is undesirable. Since procedures should ALWAYS be in MODULEs, one
could simply give the name of (one of) the MODULE(s) to the file; since
the latter is unique, the former would be as well, solving the problem
in the previous paragraph.
It thus seems a good idea to me, in all code which is not standalone
(particularly that which is publicly distributed) to preced all MODULE
names with something likely to make it unique: I precede mine with
HELBIG_, NAG could (does?---I won't be installing the NAG F90 stuff for
a few weeks yet) precede theirs with NAG_ etc. As mentioned above, the
source files would thus also have unique names.
The NUMERICAL RECIPES don't precede their MODULE names with NUMREC_ or
whatever, so one has to be careful here.
On a related note, IIRC it was Clive Page who mentioned 5 MODULE
strategies a while back, and asked for discussion. I was surprised
there was not more. This was more concerned with INTERFACEs than with
object files. Let me recap briefly his 5, add two of my own, and ask if
there is any reason to do anything other than that which I prefer.
1. Do nothing. Access procedures as in FORTRAN77, as EXTERNAL.
This is obviously not a good choice, as it makes no use of
good F90 features.
2. Hand code INTERFACEs into the calling routines.
Better, but means duplicated code, is error prone and there is
no guaranteed consistency between INTERFACE and procedure. One
is also not forced to write an INTERFACE, and could still call
routines as EXTERNAL.
3. Put all routines in one MODULE.
Easy, no duplication and guaranteed consistency. Might be OK for
people who only do a minimum of Fortran coding (in which case
it becomes equivalent to 7. below). However, any changes mean
recompiling the whole thing, things from other sources might not
be available as source code, and the linker would presumably load
the whole large chunk of object code even if only one routine were
needed. Nothing can be called EXTERNALly.
4. Keep the routines more or less one to a file, but put all
INTERFACEs in one module. No recompilation problem, no need to
load more code, easy to use. However, there is no guaranteed
consistency, and it is still possible to call the routines as
EXTERNAL procedures. (This is the policy adopted by the
NUMERICAL RECIPES, by the way.)
5. Have one routine per MODULE and one MODULE per file. Automatic
consistency, cannot be called EXTERNALly, no recompilation or
large code problems. However, any complicated code would have
very many USE statements. This is the first serious choice, and
does have something going for it---all the advantages, and
nothing must be decided as a matter of taste. However, there are
too many USE statements to remember.
6. Like 5., but have several MODULEs which consist only of USE
statements, such that things which are used together need only
have one USE statement in the calling routine. Avoids the
disadvantage of 5 and thus looks pretty good.
7. As far as the user is concerned, the same as 6., but the several
MODULEs would not have USE statements for other MODULEs
(consisting essentially of one routine) but rather the code for
these routines. At the slight cost of making the linker
occasionally load a bit too much code, this would keep related
routines in one file and would thus be easier to maintain.
Also, if one needs global data known only to these routines,
this MODULE file would be the logical place for that, the
routines accessing it by host association and not, as would have
to be the case in 5. or 6., through a USE statement. Again,
easier to maintain.
Obviously, I prefer option 7, though 6. might be an alternative if the
individual routines are quite large. Presumably, the linker could be
smart enough only to load code for those actually required, so perhaps
6. is only necessary, if at all, until linkers become smarter. (I don't
know how easy this would be to implement.) As noted above, if one does
only a small amount of coding, 7. is equivalent to 3.
Comments on both the issue of where names should be unique and which
MODULE strategy is best are more than welcome; if there is not general
interest in this, there should be, at least among those who write code
which is used (or USEd) by others.
--
Phillip Helbig Email .......... [log in to unmask]
Nuffield Radio Astronomy Laboratories Tel. ..... +44 1477 571 321 (ext. 297)
Jodrell Bank Fax ................. +44 1477 571 618
Macclesfield Telex ................. 36149 JODREL G
UK-Cheshire SK11 9DL Web .... http://www.jb.man.ac.uk/~pjh/
My opinions are not necessarily those of NRAL or the University of Manchester.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
