Fortran - Module Scope

Author

Module Scope

Gareth Owen

2006-01-24, 3:57 am

The discussion of modules going in and out of scope, and the effect on
SAVEd and unSAVEd variables has left me somewhat

, and
possibly in a position where I'm using variables that the compilers
SAVEs, but which I should explicitly SAVE.

-----------------------------------------------------------------------------
module globals
real glob(1:100)
end module globals
-----------------------------------------------------------------------------
module subs
use glob
contains
subroutine alter_glob
glob = 5.0
end subroutine
end module subs
-----------------------------------------------------------------------------
program main
use subs
call alter_glob
print*, glob
end program main
-----------------------------------------------------------------------------

Does glob go out of scope in main because globals is not explicitly
USEd there, or have I completely misunderstood?

Should glob be explicitly SAVEd if I want to reference it in main?

Catherine Rees Lay

2006-01-24, 7:56 am

Gareth Owen wrote:
> The discussion of modules going in and out of scope, and the effect on
> SAVEd and unSAVEd variables has left me somewhat

, and
> possibly in a position where I'm using variables that the compilers
> SAVEs, but which I should explicitly SAVE.
>
> -----------------------------------------------------------------------------
> module globals
> real glob(1:100)
> end module globals
> -----------------------------------------------------------------------------
> module subs
> use glob
> contains
> subroutine alter_glob
> glob = 5.0
> end subroutine
> end module subs
> -----------------------------------------------------------------------------
> program main
> use subs
> call alter_glob
> print*, glob
> end program main
> -----------------------------------------------------------------------------
>
> Does glob go out of scope in main because globals is not explicitly
> USEd there, or have I completely misunderstood?
>
> Should glob be explicitly SAVEd if I want to reference it in main?

I think you're OK. The problem as I understand it comes when your main
program doesn't reference the module either directly or indirectly, but
two subroutines both of which are called by the main program both do.

Something like...

program main

call sub1
call sub2

.....

subroutine sub1

use global

.....

subroutine sub2

use global

.....

This all looks very safe (and mostly it will work fine) but starts
looking shakier when you consider that the main program might be written
in a different language with the two subroutines in, say, a DLL. I've
not encountered a problem with a recent compiler, but the old Microsoft
ones used to happily fill unsaved common blocks with junk in this
situation, although the values were saved if everything was in one
executable. And since "mostly it works fine" bugs are the hardest to
fix, I always assume the worst :-)

One query for those more expert than me - does SAVE by itself in a
module apply only to the module variables, or does it also apply to
local variables in any routines?

Catherine.

Michael Metcalf

2006-01-24, 7:56 am

"Catherine Rees Lay" <spamtrap@polyhedron.com> wrote in message
news:_audncB8p7NXZ0jenZ2dnUVZ8tydnZ2d@ec
lipse.net.uk...
>
> One query for those more expert than me - does SAVE by itself in a module
> apply only to the module variables, or does it also apply to local
> variables in any routines?
>
Such a SAVE statement would apply only to the scope of the module, so not to
any module procedures (and hence local variables) that it might contain. We
try to explain this in section 7.9 of "Fortran 95/2003 Explained", where
it's perhaps helpful to look at Fig. 5.10 too.

Regards,

Mike Metcalf

Catherine Rees Lay

2006-01-24, 7:02 pm

Michael Metcalf wrote:
> "Catherine Rees Lay" <spamtrap@polyhedron.com> wrote in message
> news:_audncB8p7NXZ0jenZ2dnUVZ8tydnZ2d@ec
lipse.net.uk...
> Such a SAVE statement would apply only to the scope of the module, so not to
> any module procedures (and hence local variables) that it might contain. We
> try to explain this in section 7.9 of "Fortran 95/2003 Explained", where
> it's perhaps helpful to look at Fig. 5.10 too.
>
> Regards,
>
> Mike Metcalf
>
>
Thanks Mike! I have the 90/95 version which I'd looked at but not fully
understood the implications for local variables. I must get the more
recent one.

Catherine.

Michael Metcalf

2006-01-24, 7:02 pm

"Catherine Rees Lay" <spamtrap@polyhedron.com> wrote in message
news:UYydncCKQKtgqUveRVnytw@eclipse.net.uk...
> Thanks Mike! I have the 90/95 version which I'd looked at but not fully
> understood the implications for local variables. I must get the more
> recent one.
>
In all honesty, there is little or no difference in the sections cited
between the two versions!

Regards,

Mike Metcalf

Richard E Maine

2006-01-24, 7:02 pm

Gareth Owen <usenet@gwowen.freeserve.co.uk> wrote:

> Does glob go out of scope in main because globals is not explicitly
> USEd there, or have I completely misunderstood?

As Catherine says (in slightly different words), globals *IS* USEd in
the main program. The USE is indirect, but that doesn't matter for
current purposes.

A more "interesting" case would be if module subs had a PRIVATE
statement and then did not make anything from globals public. You'd have
to change main to not reference globs; maybe instead have main call a
print_glob subroutine in module subs. I think I recall that this would
still count as indirectly USEing module globals in main, even though not
a single thing from it was accessible. I'd have to check the fine print
to be 100% sure on that one, but I think it would still "count".

> Should glob be explicitly SAVEd if I want to reference it in main?

You don't need to per the standard. However, my personal advice is to
SAVE it anyway because that's an obscure condition. Just because the
standard has a fairly complicated-condition, that doesn't mean that you
have to sit exactly on the line and SAVE only when required. Remember
that it is still allowed to SAVE in other conditions.

My personal advise is to follow the priciples of modularization here.
Don't look outside of the module to determine whether a module variable
needs to be saved or not. That introduces a spurious dependency that is
error-prone and could cause problems if the code outside of the module
changes. Instead, look at the module itself and consider whether the
variable is of a nature that sensible should be SAVEd between references
or whether it is some kind of temporary that has no useful purpose in
SAVEing. To save (no pun intended) you the work, the answer for public
variables of a module is almost always that it makes sense to SAVE them.
I'd have to work a bit to come up with a public variable that it didn't
make sense to SAVE. It is trivial enough to come up with examples where
private nonsaved variables make sense, but I'd really have to think
about how to make a sensible (to me) public one.

It is good, as a general principle, to know the rules. But you don't
actually have to stand right on the edge of the cliff. After all, you'll
have to work pretty hard to come up with any case where a SAVE hurts for
a module variable. Examples for non-module variables exist. But it is
extra difficult for module variables because first you'd have to find a
compiler that didn't effectively SAVE all module variables anyway;
lacking such a compiler, any explanation of how it might hurt is an
excercise in abstract theory. Yes, I could come up with cases in the
abstract. (One way it could hurt in the abstract is by taking up memory
that isn't really needed any more).

So for the most part, I recommend just SAVing module variables as a
routine habit, rather than agonizing over whether the standard requires
it in each particular case.

Sort of like the reason that I personally use the double colon on pretty
much all of my type declaration statements, whether they need it or not.
Yes, I know the rule, but it is simpler and less error prone to just use
the double colon on every type declaration statement than to fusss with
whether each particular statement requires it.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Gareth Owen

2006-01-24, 7:02 pm

nospam@see.signature (Richard E Maine) writes:

> Gareth Owen <usenet@gwowen.freeserve.co.uk> wrote:
>
>
> As Catherine says (in slightly different words), globals *IS* USEd in
> the main program. The USE is indirect, but that doesn't matter for
> current purposes.

That's what I'd always believed, but I couldn't see how else a module
might be considered to go out of scope. What I'd overlooked was the USE
occuring in a contained subroutine, rather than the main program.

> A more "interesting" case would be if module subs had a PRIVATE
> statement and then did not make anything from globals public.

Presumably, a USE : ONLY statement would be a similar case.

> My personal advise is to follow the priciples of modularization here.
> Don't look outside of the module to determine whether a module variable
> needs to be saved or not.

That seems eminently sensible.

> To save (no pun intended) you the work, the answer for public
> variables of a module is almost always that it makes sense to SAVE
> them.

I guess thats why I'd assumed they were always (effectively) saved.
And, given how I use modules, that does appear to be the case.

Thank you for your thorough answer. I feel smarter for having read
it, and thats an increasingly rare thing on Usenet.

Sponsored Links