On 2005-08-27 17:03:19 -0300, "Lynn" <nospam@xxxxxxxxxx> said:
If you want the most thorough checking, you put your procedures in
modules. That doesn't have a very close C/C++ analogue. The closest I
can come is that the Fortran compiler auto-generates an equivalent of a
C header file, including function prototypes.
Can I put all 3500 subroutines (and functions) into one module ?
Sure. Except the resulting object code might cause indegestion for
some compilers. At least one of the major vendors has (maybe it
has been fixed but they have not publicized it if so!) a code
relocation scheme suitable for folks who keep their subroutines
below some huge size. The module looks like a single subroutine
to them and suddenly huge is not very big any more. Their relocation
dictionary overflowed at 32k entries or some such technical glitch.
OPen Watcom F77 says that we have 500,000 symbols since we have
to compile our code with global SAVE and ZERO turned on.
If you really need global SAVE and ZERO then you have a problem
which is unfortunately not that uncommon.
Sounds like you need a background project to fix the uninitialized
variable dependence. Salford FTN77 would be your ticket for what
would politely be called a legacy mess. Their F77 is solid and they
have excellent uninitialized variable checking assuming you have
adequate test cases. Using FTN77 to clean things even a bit up will
make any move to F90 easier as well. They will even catch bad calls
and out of range subscripts as well. But you have to be willling
to run with all the diagnostics turned on. (I have heard objections
to turning on the diagnostics to the effect that it would slow things
down. For testing!! One assumes that such folks prefer fast wrong
answers to right answers. And one hopes they will grow up sometime.)
You will have to watch the semantics of external functions.
The old good practice of declaring external functions will be asking
for things outside the module and will cause trouble. If you are
passing subroutine names the same issue arises.
Uh, we do that extensively for the matrix manipulation subroutines.
Only about 100 places or so.
I already broke Intel Visual Fortran 8.x a couple of years ago when I
first tried to port to it. We have all 3500 subroutine in seperate files.
Broke the linker trying to link 3500 object files ! They fixed it though.
Re: DPROD issues ... a switch like that typically ... makes a compiler nonstandard in that mode. ... treatment of specific intrinsics is one ...subroutine sub1a ... (comp.lang.fortran)
Re: Jumping into block of an if construct ... (For that matter a clever enough compiler could replace this PUT DATA ... routine which itself executes the loops around element handling. ... Either way I think the cost of element handling will usually ... So locally based on subroutine arguments, but not on, for example, ... (comp.lang.fortran)
Re: Bus error/ segmentation fault--help? ... When I compile with the intel fortran compiler,... This subroutine integrates the function y3 up one step, ... implicit double precision (a-h, o-z) ... (comp.lang.fortran)
Re: Question about name conflicts in Fortran ... I am hacking the g95 compiler so that it dumps the structure ...Subroutine foo... The para after the 2nd numbered list in 16.2 covers the case where the ... One of the exceptions is "a generic name may be the ... (comp.lang.fortran)
Re: using dot_product from c++ ... I tried to write a very simple subroutine where two vector are dot ... Assumed shape arrays are incompatible with mixed language use unless you code explicitly for the descriptor on the other side, which will be highly nonportable (even from one version of a compiler to another, let alone from one compiler to another). ... You should either not initialize the vectors or you should not use push_back but instead reference the location you wish to access directly. ... I guess maybe it arises because the misunderstandings between the codes multiply to put the memory manager out of whack. ... (comp.lang.fortran)
