about the order of program units
hes selex
11 of the Fortran95 standard.
while this program fails to compile by gfortran and CVF:
!module nothing
!end module nothing
program main
use nothing
end program main
module nothing
end module nothing
on the contrary of module unit, a subroutine's location is free:
subroutine sub()
print *, 'hello world!'
end subroutine sub
program main
call sub()
end program main
!subroutine sub()
! print *, 'hello world!'
!end subroutine sub
Arjen Markus
It is rather simple, if you realise what is going on:
To treat a use statement, the compiler must know about the module.
That is: the module must have been compiled before the unit that uses
it.
If the two appear in the same file, then yes, the position for the
module
should be before the first use.
Note that your code would not lead to an error message if the
intermediate
file describing the structure of the module already existed from a
previous
compile step.
Regards,
Arjen
hes selex
>
> It is rather simple, if you realise what is going on:
> To treat a use statement, the compiler must know about the module.
> That is: the module must have been compiled before the unit that uses
> it.
>
>
thank your reply.
but, can a compiler scans the whole program to find the module and
compile it before main program ?
so I think this isn't a must to limit the order ?
Arjen Markus
A compiler in general will only scan the program files in isolation.
(With the exception of all manner of interprocedural optimisations but
that is very much later in the process.)
It is therefore up to you to:
- Make sure that files are compiled in the right order
- Make sure that there _is_ a right order
More specifically:
If you have a file src_a.f90 containing subroutine A which references
module B,
then module B must be compiled before subroutine A:
- If B is also in src_a.f90, it should be positioned before the code
for
subroutine A
- If B is in a file src_b.f90, compile src_b.f90 first
You can create an ordering and dependencies such that the compiler can
not
handle it:
src_a.f90: subroutine A which uses module B, and a module C
src_b.f90: module B using module C
Unless you have a small program and want to keep everything in a
single file,
then this is the simplest organisation:
- Put modules in separate files
- Put the main program in a separate file
Regards,
Arjen
hes selex
> More specifically:
> If you have a file src_a.f90 containing subroutine A which references
> module B,
> then module B must be compiled before subroutine A:
> - If B is also in src_a.f90, it should be positioned before the code
> for
> subroutine A
> - If B is in a file src_b.f90, compile src_b.f90 first
all the examples in the f95 standard textbook comply with this rule,
but I can't find these words in the standard.
so ,as you said ,the limit comes from compilers , I really hope a
outsmart compiler could remove it in the future.
Arjan
Once you have put 1 Module/main-program per source-file, then you can
go for the lazy
options to sort your source-files in order of dependence:
- Get mkmf.pl (the link I had is broken, so if you need it I can send
you the script via e-mail). On the site of mkmf.pl you'll find the way
to call it (you need a Perl installation, but that's not a
problem...). This will generate a Makefile for you with all
dependencies in order of dependence.
- If you use g95, then this can be done with a compile switch (but I
have never used this switch myself, so someone else will have to give
evidence about it).
(- I write my own utility to sort the sources, but this requires some
small conventions
in coding that you may not like...)
Regards,
Arjan
Arjen Markus
Mind you, this issue is not unique to Fortran: almost all programming
languages
have that problem in one form or another. There is a book on C++
(something
like Large Scale C++ Software Development by Lakatos, IIRC) that
describes
the issue of organising the classes in great detail.
Regards,
Arjen
Steve Lionel
> all the examples in the f95 standard textbook comply with this rule,
> but I can't find these words in the standard.
The words (in F95) are these:
"A USE statement specifying a module statement is a *module reference*.
At the time a module reference is processed, the public portions of
the specified module shall be available."
[11.3.1, p187]
This is generally interpreted as saying that the module must have
already been processed by the compiler.
I agree that it is certainly possible for a compiler to prescan a source
file and rearrange the order in which the program units are compiled.
This is not required by the standard, slows compilation for all files,
and, in my view, encourages poor program structure practice. It is not
astonishing to me that few compilers support this.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
hes selex
> The words (in F95) are these:
> "A USE statement specifying a module statement is a *module reference*.
> At the time a module reference is processed, the public portions of
> the specified module shall be available."
> [11.3.1, p187]
> This is generally interpreted as saying that the module must have
> already been processed by the compiler.
OK. But It has nothing to do with program units' writing order. the
standard makes no limit upon that.
a potentially series threat is that if I have a program such as:
program main
use nothing
end program main
module nothing
end module nothing
luckily if a file named nothing.mod is in the same directory of my
program, the compiler will dismiss the module in my program and use
that, so lead to a wrong result.
thank you Steve for your help. thank you all above.
Richard Maine
> I can't find any limits on the order of program units on chapter 2 and
> 11 of the Fortran95 standard.
There aren't any. The standard doesn't even define the concept of a
source file at all, much less the order of program units within it.
Steve cites a passage that he interprets as requiring this order.
Unfortunately, that passage uses some pretty vague terms that the
standard never defines. The definition is basically up to the compiler
vendor, which is pretty much like not having the requirement in the
standard at all. For example, one plausible interpretation is that the
source code for the referenced module must at least be previously
written (as opposed to independent compilation, where you can compile
some program units before even writing some others). I suppose it serves
as a hint that the compiler might require something, details
unspecified.
These limitations are all compiler dependent. Yes, it is certainly
possible for a compiler to handle arbitrary order of program units, but
many (most?) don't. As others have noted elsethread, the limitations are
pretty typical of not only many Fortran compilers, but even many
languages.
While the limitation can be slightly annoying, I'd personally say that
was all it was and that the cost/benefit of the extra compiler
development required to make it work wasn'g good enough.
As an example of the annoyance, if the entire program is in one file, I
find it most natural for reading cmprehension to have the main program
first in order to give an overview of what is going on. I recall the
necessity of putting the top-level code last as one of the things that
annoyed me about Pascal (the original Pascal, rather than the later
extensions that had ways around this).
For best portability, I'd generally recommend either sticking with this
limitation (even if you happen to be using a compiler that doesn't
require it) or keeping separate program units in separate files.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
hes selex
> file and rearrange the order in which the program units are compiled.
> This is not required by the standard, slows compilation for all files,
> and, in my view, encourages poor program structure practice. It is not
> astonishing to me that few compilers support this.
>
in my view ,to build a good porgramming habit is a resibonsibility of
something like "code complete" or "code craft" instead of a compiler
whose duty is to comply with standard and give a correct binary.
regards.
Steve Lionel
> hes selex <lin...@sohu.com> wrote:
>
>> I can't find any limits on the order of program units on chapter 2 and
>> 11 of the Fortran95 standard.
>
> There aren't any. The standard doesn't even define the concept of a
> source file at all, much less the order of program units within it.
> Steve cites a passage that he interprets as requiring this order.
A minor clarification. I interpret that passage as allowing a compiler
to require such ordering. I agree that it is vague.
Craig Powers
>> It is rather simple, if you realise what is going on:
>> To treat a use statement, the compiler must know about the module.
>> That is: the module must have been compiled before the unit that uses
>> it.
>>
>>
>
> thank your reply.
>
> but, can a compiler scans the whole program to find the module and
> compile it before main program ?
That is possible, but I am not aware of any compilers that actually do so.