The USE statement provides a program unit with access to all of the public entities in a module.
The USE statement gives each program unit that it appears in complete knowledge of and access to the public variables and procedures contained within a module. It is important that you learn the basic rules that are associated with this statement in order to master the use of modules.
The first thing that you need to know about this statement is were it must appear in your program units. The only statements that are allowed to appear before it are the initial function, program, subroutine and module statements. No other code, executable or non-executable, can appear before a use statement.
Next, as the previous paragraph hinted at, one module can use another module. The only restriction on this is that a module can not use itself directly or indirectly. To clarify this last statement, lets say that two modules exist in a program and their names are module A and module B. It is permissible for module B to include the line
However, to include the line
inside of module B would not be permitted. Also, if module B had access to module A through the USE statement, module A could not use module B. This is because it would violate the rule of a module not being able to have indirect access to itself.
The rules that were discussed above are the basic rules concerning the USE statement. There are a few other rules that you should familiarize yourself with as you grow as a programmer.
For starters, I began the previous section by stating that the USE association grants a scoping unit total access to all of the public variables and procedures that are contained within a module. This means that USE will only grant a scoping unit access to those variables that have been marked with the public attribute or are public by default. It will not grant access to those variables and procedures that have been specified with the private attribute. You may be a little confused by this if you have never specified anything to be public before and yet the USE association has always given you access to everything inside of a module. This is because everything inside of a module automatically gets is specified as public by default.
To make things a little more interesting, the private attribute isn't the only way to block access to entities contained within a module. If you specify the " only " clause in a use statement you can further restrict access to the entities contained in a module. The best way to explain this is with an actual example, so the following is a module called stuff and two use statements that reference stuff.
Module stuff Implicit none public Real, parameter :: n = 6.02e23 real x,y,z integer k,j data x,y,z /1.0,10.0,100.0/ data i,j /1,2/ contains Subroutine alpha(p,c,d) implicit none real p,c,d P = c + d end subroutine alpha end module stuff
use stuff, only: use stuff, only: i, alpha
The first of the two use statements shown above is pointless to include in a program. When an only clause appears without any variable names trailing it, the result is that no variables from the module can be accessed by the scoping unit. The second of the two use statements can actually do something useful. The result of the second USE statement would be that the scoping unit in which it appears could only have access to the variable i and the subroutine alpha. The rest of the variables in stuff would be inaccessible to that program unit.
There is one more thing that you can do with the USE statement. You can also rename module variables upon entrance to the program unit. This could be useful if the name of a variable in the program unit clashes with the name of a variable inside of the module. For instance, lets say I wanted to use the module stuff from the last example and I wanted to rename the variable "z" with the new name of "tree" upon entry to the program unit I was working in. To do this the use statement would look like this:
use stuff, z => tree
Further examples of these more advanced topics are provided inside of the program use2.f. Make sure that you read all of the comments to stay on top of what is going on inside of the program.
examples: trapz2.f and fall3.f
Written by Jason Wehr : email@example.com and Maintained by John Mahaffy : firstname.lastname@example.org