Re: use module to pass data between procedures

On Thu, 24 Apr 2008 00:38:34 -0700 (PDT), Mike wrote:
On Apr 23, 10:31 pm, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:
Dave Seaman <dsea...@xxxxxxxxxxxx> wrote:
The problem is
using the same name in two conflicting ways.

And for all the compications in the standard-speak technically defining
it, it ain't exactly rocket science. The compiler needs to know what you
are talking about. If a single scope has both an SZ as a dummy argument
and an SZ as a module variable, then when you say SZ, it has no way to
tell which one is meant. That's all.

If you do need to access both things, there are ways to, for example,
rename the module variable for the scope in question. But I have a
feeling that perhaps the OP actually wants a dummy argument and a module
variable to actually be the same thing instead of just having access to
one.
I am thinking module var. SZ and dummy argument SZ in memory.
Are they located in the same address or different addresses?
I think they are in different addresses. Because they are the same
name and in different addresses, they are not allowed.
Am I right?

Mike
That can't be. Again, the compiler has to know which place to find
the variable; it can't be in both.

Perhaps this example will help.


module scoping

implicit none
integer :: sz ! sz is a module variable

contains

subroutine a
sz = 3 ! this changes the module variable sz
end subroutine a

subroutine b
integer :: sz ! sz is a local variable
sz = 5 ! this changes the local variable sz
end subroutine b

subroutine c(sz)
integer, intent(inout) :: sz ! sz is a dummy argument
sz = sz + 1 ! this changes the dummy argument sz
end subroutine c

end module scoping


The scope of a local variable or a dummy argument is just the procedure
containing that declaration. The scope of a module variable is the
entire module, *excluding* any procedure that has a local variable or
dummy argument of the same name. The scope of the module variable SZ
here is the entire module, *except* for subroutines B and C, which have
overridden the name SZ to mean something else.

The rule is that you can't have a variable declared twice in the same
scope. The module above does not violate this rule, because the
different instances of SZ are declared in different scopes. The rule
means that you can't declare SZ twice as a module variable in the same
module, or declare it once as a module variable and also import a
variable of the same name from some other module in a USE statement.

However, you could do something like this:

module othermod

use scoping, othersz => sz
implicit none

real :: sz

[ ... ]

This is not a conflict, because the SZ from module SCOPING has been
renamed to OTHERSZ in the current scope, allowing SZ in this module to
refer to the REAL variable declared here.

--
Dave Seaman
Third Circuit ignores precedent in Mumia Abu-Jamal ruling.
<http://www.indybay.org/newsitems/2008/03/29/18489281.php>

.

Relevant Pages

  • Re: FORMAT and INDEX problems
    ... >What do I have to undersand under a "dummy" argument? ... when you declare a function or ... subroutine F, X and Y are dummy arguments and may be declared ... You may also use *when declaring a character constant ...
    (comp.lang.fortran)
  • array-valued function as dummy argument
    ... can one declare a dummy argument that is a function whose ... without having to write an interface block for it? ... and I wanted to write a subroutine that could use either. ... Unfortunately two different compilers told me that a dummy argument ...
    (comp.lang.fortran)
  • Re: Where to declare variables
    ... Scope IS the answer to your question. ... There is very little reason to declare a variable globally when it ... declared at the subroutine level. ... What are the pros and cons of keeping a variable private ...
    (microsoft.public.access.gettingstarted)
  • Re: use module to pass data between procedures
    ... May I ask what "scope" is? ... I do have SZ as the dummy argument in the procedures of many modules. ... SUBROUTINE FCN ... So I have to declare a module variable SZ. ...
    (comp.lang.fortran)
  • Re: Form k = i + j and test for overflow.
    ... Brooks Moses wrote: ... One would not expect to call a subroutine without ... I had originally written it as a contained subroutine, and when I moved it to external to emphasize the separate compilation, I forgot to declare it. ... The dummy in foo is also kind 1. ...
    (comp.lang.fortran)