On Apr 25, 11:28=A0am, Dave Seaman <dsea...@[EMAIL PROTECTED]
> wrote:
> On Thu, 24 Apr 2008 19:32:55 -0700 (PDT), Mike wrote:
> > 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.
>
> [ ... ]
>
>
>
>
>
> >> 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
arg=
ument
> >> =A0 =A0 =A0 sz =3D sz + 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
!=
this 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? =A0Does it mean that SZ extends to program or
> > procedure?
>
> If any scoping unit contains a USE statement, the effect is the same as
> if all the PUBLIC variables in the USEd module were declared at that
> point. =A0The scope is the program, module, or procedure that contains
the=
> USE statement, exactly as it would be for any ordinary variable
> declaration.
>
> >> The rule is that you can't have a variable declared twice in the same
> >> scope. =A0
>
> Note carefully the words "in the same scope". =A0That's the whole point
of=
> the example. =A0You can have two different variables with the same name,
> provided they are in different scopes.
>
> > 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?
>
> I only see one variable SZ in either scope. =A0The rule says you can't
hav=
e
> two variables named SZ in the same scope, but it's perfectly ok to have
> one, which is shared between both. =A0That's exactly what the USE
statemen=
t
> is designed to do.
>
>
>
>
>
> > 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
> > =A0 =A0 use scoping, othersz =3D> sz
> > =A0 =A0 implicit none
> > =A0 =A0 real :: sz
> > contains
> > =A0 =A0subroutine app(sz)
> > =A0 =A0 =A0 integer, intent(inout) :: sz =A0 =A0 =A0! sz is a dummy
argu=
ment
> > =A0 =A0 =A0 sz =3D sz + 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
! =
this changes the dummy
> > argument sz
> > =A0 =A0end subroutine app
> > end module othermod
>
> Ok, so far.
>
> > program main
> > =A0 =A0use scoping
> > =A0 =A0use othermod
>
> You can't do this, because both modules have a public variable named SZ,
> and this would cause both to be im****ted into the scope of program MAIN.
> You need to modify at least one of those USE statements above to prevent
> this, perhaps by using a rename clause or an ONLY clause, so that the
> name SZ is im****ted only once.
>
> > =A0 =A0 implicit none
> > =A0 =A0sz=3D10.
> > =A0 =A0print *,sz
> > =A0 =A0call a
> > =A0 =A0print *,sz
> > =A0 =A0call b
> > =A0 =A0print *,sz
> > =A0 =A0call c(sz)
> > =A0 =A0print *,sz
> > =A0 =A0call app(sz)
> > =A0 =A0print *,sz
> > end
> > It seems in 4th line "real :: sz" needs to be replaced by =A0"real ::
> > othersz".
>
> You mean in module OTHERMOD? No, that's not allowed. =A0The name OTHERSZ
> already refers to a variable in module SCOPING (because of the rename
> clause "othersz =3D> sz"), and therefore you cannot redeclare it in
module=
> OTHERMOD. =A0However, if you change the name SZ in OTHERMOD to something
> else that doesn't conflict with any other names in that scope, that will
> solve the conflict that arises from USEing both modules in program MAIN.
>
> > In the subroutine app(sz), the dummy argument is sz. =A0It has no
> > compiled error.
> > Why? =A0didn't you mean I need to rename SZ to othersz as a dummy
> > argument?
>
> No, because the two variables are in different scopes. =A0The one
im****ted=
> from module SCOPING has a scope here that is equal to module OTHERMOD,
> *excluding* subroutine APP, which has a dummy argument by the same name
> that shadows (renders invisible) the one im****ted from SCOPING.
>
> --
> 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 -- Hide quoted text -
>
> - Show quoted text -
Since I have a lot conflict variables with module files in main
program, to prevent rename so many, I use derived type.
Declare a derived type in the module like:
module XXX
type ComboVar
real :: sz
...... !all of the arguments need to pass to some procedure
end type ComboVar
type(ComboVar) :: cVar
Then in main program
use XXX, cVar1=3D>cVar
cVar1=3DComboVar(sz,.....); <=3D=3D to prevent modifying so many sz in
main=
program.
Thank you very much.
Mike
|
