MODULE variables and SAVE

Is the following correct as of Fortran95?

MODULE variables (i.e. before CONTAINS) without the SAVE attribute are
not necessarily saved unless they are used by the main program. So,
PRIVATE variables used by the routines in the module but not by the main
program need to be SAVEd if one wants them to keep their values between
calls to routines in the module. If the variable is USEd by the main
program, then SAVE is not necessary (but doesn't hurt), even if the main
program does nothing (i.e. neither using nor assigning a value to) the
variable). Variables with an initial value given in the declaration are
always saved.

Has anything changed since Fortran95?

Am Montag, 9. April 2012 14:24:09 UTC+2 schrieb Phillip Helbig---undress to reply:
> Is the following correct as of Fortran95?
>
> MODULE variables (i.e. before CONTAINS) without the SAVE attribute are
> not necessarily saved unless they are used by the main program. So,
> PRIVATE variables used by the routines in the module but not by the main
> program need to be SAVEd if one wants them to keep their values between
> calls to routines in the module. If the variable is USEd by the main
> program, then SAVE is not necessary (but doesn't hurt), even if the main
> program does nothing (i.e. neither using nor assigning a value to) the
> variable). Variables with an initial value given in the declaration are
> always saved.
>
> Has anything changed since Fortran95?

Well, your statement of the situation is not quite correct: it depends on the *module* being accessed in a main program, not (necessarily) the variables it contains (MFE, Section 7.9).

Regards,

Mike Metcalf

In article
<20308249.54.1333975002410.JavaMail.geo-discussion-forums@yngo16>,
michaelmetcalf@compuserve.com writes:

> > MODULE variables (i.e. before CONTAINS) without the SAVE attribute are
> > not necessarily saved unless they are used by the main program. So,
> > PRIVATE variables used by the routines in the module but not by the main
> > program need to be SAVEd if one wants them to keep their values between
> > calls to routines in the module. If the variable is USEd by the main
> > program, then SAVE is not necessary (but doesn't hurt), even if the main
> > program does nothing (i.e. neither using nor assigning a value to) the
> > variable). Variables with an initial value given in the declaration are
> > always saved.
> >
> > Has anything changed since Fortran95?
>
> Well, your statement of the situation is not quite correct: it depends
> on the *module* being accessed in a main program, not (necessarily) the
> variables it contains (MFE, Section 7.9).

So even if they are PRIVATE, they are still SAVEd?

M&R in 7.9 says "...use of variables in modules...the variable becomes
undefined unless the main program acccesses it..." where it seems to be
talking about the variable, not the module. Surely if the varialbe is
PRIVATE to the module the main program cannot be accessing it.

Is MFE an update to M&R?

Am Montag, 9. April 2012 14:59:48 UTC+2 schrieb Phillip Helbig---undress to reply:

> Is MFE an update to M&R?

No. MFE ("Modern Fortran Explained") is an update to MR&C which was, in 2004, an update to M&R. The version you appear to have is very out of date. The standard hasn't changed, we just have better wording now.

Regards,

Mike Metcalf

<michaelmetcalf@compuserve.com> wrote:

> Am Montag, 9. April 2012 14:24:09 UTC+2 schrieb Phillip Helbig---undress
to reply:
> > Is the following correct as of Fortran95?
> >
> > MODULE variables (i.e. before CONTAINS) without the SAVE attribute are
> > not necessarily saved unless they are used by the main program. So,
> > PRIVATE variables used by the routines in the module but not by the main
> > program need to be SAVEd if one wants them to keep their values between
> > calls to routines in the module. If the variable is USEd by the main
> > program, then SAVE is not necessary (but doesn't hurt), even if the main
> > program does nothing (i.e. neither using nor assigning a value to) the
> > variable). Variables with an initial value given in the declaration are
> > always saved.
> >
> > Has anything changed since Fortran95?
>
> Well, your statement of the situation is not quite correct: it depends on
> the *module* being accessed in a main program, not (necessarily) the
> variables it contains (MFE, Section 7.9).

Furthermore, a couple of niggly points.

First, USEing the module in the main program does not make the variables
SAVEd. It just makes the SAVE attribute irrelevant because the situation
where it matters never comes up. I can't off-hand think of a case where
the distinction actually matters, but I find it easier to just get such
things right than to worry about whether it matters. In this case, it
makes for one less rule to remember, because...

The only thing special about the main program is that it never returns,
so it is always "active". There is no special rule just for the main
program. That's just the application of the regular rule plus the fact
that the main program is always active. You would get the same effect
from using the module in any other procedure that happens to be active
for the whole time of interest (if there is such a procedure).

I recommend using the SAVE attribute explicitly instead of this kind of
hack. The hack reminds me of the same thing that some people did back in
the bad old days of COMMON. In my opinion, having the main program
directly access every module (or common block) in the whole application
is horrible from the perspective of information hidding. It is pretty
much the opposite of information hiding. The main program has no need to
know that level of detail. So put the SAVE where the information is
relevant (in the module) instead of having it affect the main program,
which might not even need to know that the module exists.

I keep seeing a larger pattern of trying to avoid writing things out
explicitly. I recommend the opposite. Yes, I had simillar tendencies in
my foolish youth, but I learned to regret it.

P.S. I am told that f2008 makes all module variables automatically
SAVEd, though I don't even have any f2003 compilers yet myself.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

In article <1ki9xjs.11t1lhh41z22oN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes:

> > > Is the following correct as of Fortran95?
> > >
> > > MODULE variables (i.e. before CONTAINS) without the SAVE attribute are
> > > not necessarily saved unless they are used by the main program. So,
> > > PRIVATE variables used by the routines in the module but not by the main
> > > program need to be SAVEd if one wants them to keep their values between
> > > calls to routines in the module. If the variable is USEd by the main
> > > program, then SAVE is not necessary (but doesn't hurt), even if the main
> > > program does nothing (i.e. neither using nor assigning a value to) the
> > > variable). Variables with an initial value given in the declaration are
> > > always saved.
> > >
> > > Has anything changed since Fortran95?
> >
> > Well, your statement of the situation is not quite correct: it depends on
> > the *module* being accessed in a main program, not (necessarily) the
> > variables it contains (MFE, Section 7.9).
>
> Furthermore, a couple of niggly points.
>
> First, USEing the module in the main program does not make the variables
> SAVEd. It just makes the SAVE attribute irrelevant because the situation
> where it matters never comes up. I can't off-hand think of a case where
> the distinction actually matters, but I find it easier to just get such
> things right than to worry about whether it matters. In this case, it
> makes for one less rule to remember, because...
>
> The only thing special about the main program is that it never returns,
> so it is always "active". There is no special rule just for the main
> program. That's just the application of the regular rule plus the fact
> that the main program is always active. You would get the same effect
> from using the module in any other procedure that happens to be active
> for the whole time of interest (if there is such a procedure).

Right; that's clear.

> I recommend using the SAVE attribute explicitly instead of this kind of
> hack. The hack reminds me of the same thing that some people did back in
> the bad old days of COMMON. In my opinion, having the main program
> directly access every module (or common block) in the whole application
> is horrible from the perspective of information hidding. It is pretty
> much the opposite of information hiding. The main program has no need to
> know that level of detail. So put the SAVE where the information is
> relevant (in the module) instead of having it affect the main program,
> which might not even need to know that the module exists.

I agree.

> P.S. I am told that f2008 makes all module variables automatically
> SAVEd, though I don't even have any f2003 compilers yet myself.

So this would be relevant for modules which are not used by the main
program?

Since the main program is always active, then variables in modules used
by it are "saved" EVEN IF THEY ARE PRIVATE TO THE MODULE?

Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de>
wrote:

> > P.S. I am told that f2008 makes all module variables automatically
> > SAVEd, though I don't even have any f2003 compilers yet myself.
>
> So this would be relevant for modules which are not used by the main
> program?

I haven't read that bit of the actual f2008 standard. I would be quite
surprised, however, if it said anything special about the main program.

> Since the main program is always active, then variables in modules used
> by it are "saved" EVEN IF THEY ARE PRIVATE TO THE MODULE?

Yes. As per Metcalf's comment, it has nothing to do with the variables
being accessed - just with the module being accessed. I might further
elaborate that it has nothing to do with the variables even being
accessible.

But then I *NEVER* take advantage of this feature anyway. If a module
variable (either private or public) needs to have a lifetime longer than
a single invocation of a procedure in the module, then I just declare
the variable to have the SAVE attribute. I don't worry about possible
intermediate needs in terms of variable lifetime. Either it needs to
outlive a single call or not, which translates into either it needs to
be SAVEd or not. For the large majority of my module variables, the
answer happens to be that they need to be SAVEd.

I think you are putting far too much thought into this one. Just SAVE
the darn things instead of worrying about all the fine points about when
you can get by without it. That's what I do. I've probably put more
thought into writing this thread than I've actually spent on the issue
in my own programs.

There was a time, back in f77 days, when I did pay a lot of detailed
attention to the comparable issue with common. That's because memory was
precious and I used some systems where I could actually control the
lifetime of common blocks in memory. In particular, I recall that most
of the common blocks used during the computation part of one of my apps
did not need to be in memory at the same time as those used in the
plotting part. Those were the bad old days. The storage for a single bit
of memoty was large enough to see with the unaided eye (well, with my
unaided eyes of those days :-().

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

Richard Maine <nospam@see.signature> wrote:

(snip, someone wrote)
>> > MODULE variables (i.e. before CONTAINS) without the SAVE attribute are
>> > not necessarily saved unless they are used by the main program.

(snip)

> Furthermore, a couple of niggly points.

> First, USEing the module in the main program does not make the variables
> SAVEd. It just makes the SAVE attribute irrelevant because the situation
> where it matters never comes up. I can't off-hand think of a case where
> the distinction actually matters, but I find it easier to just get such
> things right than to worry about whether it matters. In this case, it
> makes for one less rule to remember, because...

In the olden days, the problem of COMMON became more interesting
in the case of overlays, or similar memory management systems.
Presumably that could still be true in the case of modules, if
one was using a system with overlays.

> The only thing special about the main program is that it never returns,
> so it is always "active". There is no special rule just for the main
> program. That's just the application of the regular rule plus the fact
> that the main program is always active. You would get the same effect
> from using the module in any other procedure that happens to be active
> for the whole time of interest (if there is such a procedure).

As I remember, some linkers automatically put all COMMON in the root
segment, others as appropriate for the routines each is used in.

> I recommend using the SAVE attribute explicitly instead of this kind of
> hack. The hack reminds me of the same thing that some people did back in
> the bad old days of COMMON. In my opinion, having the main program
> directly access every module (or common block) in the whole application
> is horrible from the perspective of information hidding. It is pretty
> much the opposite of information hiding. The main program has no need to
> know that level of detail. So put the SAVE where the information is
> relevant (in the module) instead of having it affect the main program,
> which might not even need to know that the module exists.

In the case where a module might be useful in another program, then
I would have to agree. There are enough cases where the different
parts of a program are so specialized to the application at hand,
that there will never be another use for them. (Often in the programs
that are in the tens to hundreds of thousands of lines long.)

Putting the COMMON in main means that you only need to look in
one place to see all of them.

> I keep seeing a larger pattern of trying to avoid writing things out
> explicitly. I recommend the opposite. Yes, I had simillar tendencies in
> my foolish youth, but I learned to regret it.

> P.S. I am told that f2008 makes all module variables automatically
> SAVEd, though I don't even have any f2003 compilers yet myself.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Richard Maine <nospam@see.signature> wrote:
>
[some stuff about SAVE and modules]
>
> In the olden days, the problem of COMMON became more interesting
> in the case of overlays, or similar memory management systems.
> Presumably that could still be true in the case of modules, if
> one was using a system with overlays.

Yes. I used to do those common tricks myself, as I mentioned in another
post in this thread.

But to my knowledge, there are exactly zero actual implementations that
do modules this way, which was one of the arguments made for making
module variables always be SAVEd anyway (as in f2008). I'm not sure I
entirely like that decision, as it seems to close off future
possibilities, but that's apparently what passed.

> Putting the COMMON in main means that you only need to look in
> one place to see all of them.

As though that were a good thing? Sorry, but just yuck. Hey, why bother
with subroutines at all? Just put everything in the main program so you
only need to look one place to see it. I've known people who programmed
that way.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

In article <1kia0jq.1b7qk63180t6oN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes:

> > > P.S. I am told that f2008 makes all module variables automatically
> > > SAVEd, though I don't even have any f2003 compilers yet myself.
> >
> > So this would be relevant for modules which are not used by the main
> > program?
>
> I haven't read that bit of the actual f2008 standard. I would be quite
> surprised, however, if it said anything special about the main program.

Right. So, it would be relevant for modules which are not continuously
accessed.

> > Since the main program is always active, then variables in modules used
> > by it are "saved" EVEN IF THEY ARE PRIVATE TO THE MODULE?
>
> Yes. As per Metcalf's comment, it has nothing to do with the variables
> being accessed - just with the module being accessed. I might further
> elaborate that it has nothing to do with the variables even being
> accessible.

OK. M&R is at best unclear here. :-(

> But then I *NEVER* take advantage of this feature anyway. If a module
> variable (either private or public) needs to have a lifetime longer than
> a single invocation of a procedure in the module, then I just declare
> the variable to have the SAVE attribute. I don't worry about possible
> intermediate needs in terms of variable lifetime. Either it needs to
> outlive a single call or not, which translates into either it needs to
> be SAVEd or not. For the large majority of my module variables, the
> answer happens to be that they need to be SAVEd.

Same here, in all points.

On 4/9/12 11:12 AM, Richard Maine wrote:
> Phillip Helbig---undress to reply<helbig@astro.multiCLOTHESvax.de>
> wrote:
>
>>> P.S. I am told that f2008 makes all module variables automatically
>>> SAVEd, though I don't even have any f2003 compilers yet myself.
>>
>> So this would be relevant for modules which are not used by the main
>> program?
>
> I haven't read that bit of the actual f2008 standard. I would be quite
> surprised, however, if it said anything special about the main program.

Right, modules can go out of scope if they are accessed in some
subroutines but not in others; especially if the code is tree-like with
several main branches that use different modules. F2008 says module
variables behave as if they were saved. And, as a bonus, it says the
same thing about common variables.

Actually, I don't think it actually says that. It merely removes the
f2003 words that say things go away when something becomes unused. The
normal standard trick .

Dick Hendrickson
>
>> Since the main program is always active, then variables in modules used
>> by it are "saved" EVEN IF THEY ARE PRIVATE TO THE MODULE?
>
> Yes. As per Metcalf's comment, it has nothing to do with the variables
> being accessed - just with the module being accessed. I might further
> elaborate that it has nothing to do with the variables even being
> accessible.
>
> But then I *NEVER* take advantage of this feature anyway. If a module
> variable (either private or public) needs to have a lifetime longer than
> a single invocation of a procedure in the module, then I just declare
> the variable to have the SAVE attribute. I don't worry about possible
> intermediate needs in terms of variable lifetime. Either it needs to
> outlive a single call or not, which translates into either it needs to
> be SAVEd or not. For the large majority of my module variables, the
> answer happens to be that they need to be SAVEd.
>
> I think you are putting far too much thought into this one. Just SAVE
> the darn things instead of worrying about all the fine points about when
> you can get by without it. That's what I do. I've probably put more
> thought into writing this thread than I've actually spent on the issue
> in my own programs.
>
> There was a time, back in f77 days, when I did pay a lot of detailed
> attention to the comparable issue with common. That's because memory was
> precious and I used some systems where I could actually control the
> lifetime of common blocks in memory. In particular, I recall that most
> of the common blocks used during the computation part of one of my apps
> did not need to be in memory at the same time as those used in the
> plotting part. Those were the bad old days. The storage for a single bit
> of memoty was large enough to see with the unaided eye (well, with my
> unaided eyes of those days :-().
>

Dick Hendrickson <dick.hendrickson@att.net> wrote:

> F2008 says module
> variables behave as if they were saved. And, as a bonus, it says the
> same thing about common variables.
>
> Actually, I don't think it actually says that. It merely removes the
> f2003 words that say things go away when something becomes unused. The
> normal standard trick .

I was suspicious it might have been done that way.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain