Re: changing module files

From: John Lansberry (john.lansberry_at_jhuapl.edu)
Date: 12/17/03

  • Next message: meek_at_skyway.usask.ca: "RE: National Labs, Fortran, and free compilers" 
    Date: Wed, 17 Dec 2003 08:51:49 -0500

    Interestingly (at least to me), this whole thread is very closely related to
    my previous post (Will Fortran 2003 Solve This Problem).

    For me, the fact that modules must be compiled is a major obstacle to object
    oriented (OO) programming. That is, objects of different classes
    (definitions of which are encapsulated in modules) cannot USE each other
    (directly or indirectly).

    C++ header files avoid that problem, because header files only declare the
    INTERFACE to class member functions. Whether any such member function is
    actually defined somewhere is not determined until compile time. Hence, if
    the header file is wrong (provides the wrong list of arguments to a
    function), you won't know about it until link time in C++. I'm no fan of
    header files. I think they are ugly and prone to errors. Plus, you need to
    understand and be comfortable with all of the preprocessor macros. IMHO,
    requiring the use of a preprocessor to get something to compile and link
    represents a fundamental flaw in the design of the language.

    The concerns with module files are not new. Dan Nagle (in thread mentioned
    previously) refers to the "Enhanced Modules" series of papers by Van Snyder
    (www.j3-fortran.org). Mr. Synder makes the very same point that a change to
    MODULE_A may cause a ripple effect of re-compiling all other modules that
    USE MODULE_A, even if the INTERFACES to MODULE_A member functions (and/or
    TYPE definitions in MODULE_A) have not changed. Apparently, that issue is
    going to be addressed in some form (via submodules or something - I'm fuzzy
    on the details).

    John

    "Tony Jay" <Tony.Jay@nospam.bsac.com> wrote in message
    news:vu0g9me94je206@corp.supernews.com...
    > Yes.
    >
    > but a good implementation of .mod files (hopefully in IF 8) does not
    require
    > recompiling if the .mod files have not changed (apprently easy to do by
    > creating a temp .mod and only over write the original one if they are
    > different, hence the time stamp does not change)
    >
    > Just because the implemention of the compiler is not in a standard does
    not
    > mean that we should not expect compiler writers to give us a good
    > environments to work in . I do not know the fortran standard, but i expect
    > it contains very little or nothing on how a debugger should work in
    > fortran - yet i expect to be able to investigate the value of my
    variables.
    >
    > I would be interested to see which compilers do not use .mod files, it
    must
    > be quite hard to check the interfaces at compile time if there is nothing
    to
    > check against. Checking interfaces only at link time would make library
    > maintenace fun. I doubt the linker would be able to correctly report
    > problems of trying to access a private variable in a module. (I assume I
    use
    > the c++ linker to link my fortran )
    >
    > Tony Jay
    >
    > "Jan C. Vorbrüggen" <jvorbrueggen@mediasec.de> wrote in message
    > news:3FE02CDD.400718CA@mediasec.de...
    > > As I understand it, the writers of the Fortran standard wanted to offer
    > > more than just the interface functionality to compiler writers and
    > > programmers. For instance, in C++ you need to put part of the
    > implementation
    > > into the header file if you want those parts to be inlineable. So now
    > > your implementation is in two different places...bad, very bad from a
    > > sofware engineering point-of-view. In F90, all is in the actual source
    > > file, and the compiler writer must put the interface information into
    > > the module file, but he may decide, for instance, to include some
    routines
    > > in a way that they can be inlined by the module's USErs. In fact,
    nothing
    > > in the standard, AFAIK, _requires_ modules files to exist: a USE could
    > > just as well refer to the same file/entity as is later used for linking.
    > >
    > > Given that, your makefile needs to be conservative and remake all users
    > > of a module file if it was re-written.
    > >
    > > Jan
    >
    >

  • Next message: meek_at_skyway.usask.ca: "RE: National Labs, Fortran, and free compilers"

    Relevant Pages

    • Re: Win32 API and gfortran
      ... write out a module containing only interface blocks and compile the ... that the /iface switches and ATTRIBUTES directives change the compiler ... arguments are passed in the normal Fortran way ...
      (comp.lang.fortran)
    • Re: Win32 API and gfortran
      ... write out a module containing only interface blocks and compile the ... that the /iface switches and ATTRIBUTES directives change the compiler ... arguments are passed in the normal Fortran way ... There's also a quirk of our compiler you are apparently not aware of. ...
      (comp.lang.fortran)
    • Re: How calling a cpp-dll?
      ... | In cpp the string is correct, but the string in Fortran is empty. ... You should tell the compiler that StdVar_String uses whatever calling ...
      (comp.lang.fortran)
    • Re: is it possible to pass C++ vectors to fortran subroutines
      ... One is that what's in the header files is sort of communication from programmer to compiler. ... So long as the fortran code is calling the code generated by the c++ compiler, because just reading the headers isn't enough to insure compatible functionality with a particular class. ... and some limited help for C compatibility may be coming too: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm. ...
      (comp.lang.fortran)
    • Re: NAG ware linking problem
      ... Adding the following interface block ought to do the trick. ... subroutine antfarm() bind ... If you don't have version 5.1 of the compiler, ... Basically, all Fortran procedure ...
      (comp.lang.fortran)