On Apr 24, 9:20=A0pm, Dave Seaman <dsea...@[EMAIL PROTECTED]
> wrote:
> On Thu, 24 Apr 2008 00:38:34 -0700 (PDT), Mike wrote:
> > On Apr 23, 10:31=A0pm, nos...@[EMAIL PROTECTED]
(Richard Maine) wrote:
> >> Dave Seaman <dsea...@[EMAIL PROTECTED]
> 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
yo=
u
> >> 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
modul=
e
> >> 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. =A0Because 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.
>
> =A0 module scoping
>
> =A0 =A0 implicit none
> =A0 =A0 integer :: sz =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ! sz
is =
a module variable
>
> =A0 contains
>
> =A0 =A0 subroutine a
> =A0 =A0 =A0 sz =3D 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
=
=A0! this changes the module variable sz
> =A0 =A0 end subroutine a
>
> =A0 =A0 subroutine b
> =A0 =A0 =A0 integer :: sz =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ! sz
is =
a local variable
> =A0 =A0 =A0 sz =3D 5 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
=
=A0! this changes the local variable sz
> =A0 =A0 end subroutine b
>
> =A0 =A0 subroutine c(sz)
> =A0 =A0 =A0 integer, intent(inout) :: sz =A0 =A0 =A0! sz is a dummy
argume=
nt
> =A0 =A0 =A0 sz =3D sz + 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 !
th=
is changes the dummy argument sz
> =A0 =A0 end subroutine c
>
> =A0 end module scoping
>
> The scope of a local variable or a dummy argument is just the procedure
> containing that declaration. =A0The scope of a module variable is the
> entire module, *excluding* any procedure that has a local variable or
> dummy argument of the same name. =A0The 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.
thank you for your explanation.
If the program or procedure use the module scoping, how to say the
scope of SZ now? Does it mean that SZ extends to program or
procedure?
>
> The rule is that you can't have a variable declared twice in the same
> scope. =A0
If the program or procedure USE the module scoping and it has variable
SZ, does it mean SZ is in the same scope of
program main
USE scoping
SZ=3D10.
!may I say SZ is in the same scope of program main & module scoping?
end program main
The module above does not violate this rule, because the
> different instances of SZ are declared in different scopes. =A0The 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 im****t a
> variable of the same name from some other module in a USE statement.
>
> However, you could do something like this:
>
> =A0 module othermod
>
> =A0 =A0 use scoping, othersz =3D> sz
> =A0 =A0 implicit none
>
> =A0 =A0 real :: sz
>
> =A0 =A0 [ ... ]
>
> 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.
Let me add some more statements as following:
module othermod
use scoping, othersz =3D> sz
implicit none
real :: sz
contains
subroutine app(sz)
integer, intent(inout) :: sz ! sz is a dummy argument
sz =3D sz + 1 ! this changes the dummy
argument sz
end subroutine app
end module othermod
program main
use scoping
use othermod
implicit none
sz=3D10.
print *,sz
call a
print *,sz
call b
print *,sz
call c(sz)
print *,sz
call app(sz)
print *,sz
end
It seems in 4th line "real :: sz" needs to be replaced by "real ::
othersz".
In the subroutine app(sz), the dummy argument is sz. It has no
compiled error.
Why? didn't you mean I need to rename SZ to othersz as a dummy
argument?
Mike
>
> --
> Dave Seaman
> Third Circuit ignores precedent in Mumia Abu-Jamal ruling.
> <http://www.indybay.org/newsitems/2008/03/29/18489281.php>-
Hide quoted
te=
xt -
>
> - Show quoted text -
|
