> Hi fellow Fortran users (old and new)!
> I am new to Fortran but not to programming in general. I started to
> program more seriously Fortran just a couple of months ago and now I
> have come up to a cross section where I need some help to understand
> the design of Fortran 90.
> I have seen some serious issues (yes, strong word) with Fortran 90
> modules. The binary compatibility between different compilers - even
> on the same architecture - is zero.
Name mangling issues are a natural consequence of the additional
conceptual power (e.g., object based programming, encapsulation)
provided by modules. C++ has the same issues here, although there
may be more efforts to keep compatibility here (also due to g++
having been around for a long time!). Also note that even in Fortran
77 there were limits to binary compatibility (I/O).
> Also they create a terrible mess
> in the Make scripts.
There are scripts which can generate Make dependencies automagically
> I just cannot understand why Fortran 90 thought
> there was a need to reinvent the wheel - and make a terrible work
> while doing so?
> Let's look at the test module testmod.f90:
> MODULE TESTMOD
> INTEGER :: X
> SUBROUTINE COMPUTE
> END SUBROUTINE
> END MODULE TESTMOD
> Between the three different compilers I have available I see the
> following difference in the object files:
> gfortran 4.2
> 00000000 T __testmod__compute
> 00000000 B __testmod__x
> Intel Fortran 9.1
> 00000000 T testmod._
> 00000002 T testmod_mp_compute_
> 00000004 C testmod_mp_x_
> Sun studio 12
> 00000000 T testmod.compute_
> 00000000 B testmod.x_
> 00000000 D testmod_
> Also the .mod file is different. <sarcasm>The new Fortran 2003
> standard talks about C integration. How about to start with Fortran <-
>> Fortran integration? </sarcasm>
> This means that you cannot compile a library with say gfortran and use
> it in any other compiler.
> If you avoid using Fortran modules you can get something that is
> binary compatible and usable between the three compilers I have
> available and have also tested with. I have  a small example of how
> to write "module code" without using modules. It boils down to using
> INCLUDE instead. There are some negativisms with not using MODULES as
> well but not as many.
For large scale and object based programming or library design, using "include"
will not do the job. Note in particular that
* distinctive types are generated per include, as opposed to modules.
This makes e.g. passing objects of a type to an external subroutine impossible.
* encapsulation features are *only* available for modules
> Leading researchers is using Fortran 95  with modules I guess I
> just have to bend over and recognize that this is broken but nobody
> but me seems to care about it. Also, if you look at the BLAS95
> proposal routines, you see lot's of dangerous code. You see unsafe
> EXTERN keywords. I would though out modules and replace it with type
> checking any day of the week (Do not confuse modules with
> I think Fortran 90 has lot's of nice features which I think is
> essential to a modern programming language. I know I don't have to
> follow everyone else and use MODULES. I don't even have to use Fortran
> 90. But since so many are choosing to use modules and seems fine with
> that - where did you dispose of the bodies of those who questioned it?
> Thanks for your comments. I would very very much like to hear what you
> have to say about these things.
>  http://na37.nada.kth.se/mediawiki/in..._the_seventies
>  http://www.cs.umd.edu/~stewart/matran/Matran.html
> Henrik Holst, Sweden