[Gerry Kan]

Howdy Folks:

I come across this code snippit verbatim when I am editing a F90 module:

! ... preceding code

    IMPLICIT NONE

    PRIVATE
    SAVE

! ... proceeding code

I know what PRIVATE and SAVE do individually, but what happens when they are together like this?

Also, I thought the PRIVATE keyword has to be assigned to something in order for it to work, like

! ... code before

INTEGER :: X

! ... some more code in between 

PRIVATE X

! ... even more code afterwards

Any ideas on this would be very helpful.

Thanks in advance, Gerry.

[sbaffini]

The PRIVATE statement in a module, without any further identifier, or PUBLIC statement anywhere else, should just make the whole module unusable from outside it.

The SAVE statement alone in the module (as opposed to within a subroutine or function) should instead have no effect at all. I'm not sure about this but, as I have seen this as well, it might have something to do with earlier implementations/users of F90. It seems people were unsure about the fact that module global variables would retain their values. They do without any need for SAVE (in contrast to variables whose scope is limited to subroutines or functions, but in that case the SAVE attribute should be in the subroutine/function).

So, SAVE seems just an old, bad, but unharmful (as for now) habit. If the module is used somewhere else than, you will probably find some PUBLIC statement somewhere in the module. Obviously, this is just as bad coding as it appears, because there is no reason to disperse such statements over the whole module without, at least, a comment about it.

[sbaffini]

Let me point you to this perfect explanation by Damian Rouson about the SAVE attribute for module variables https://github.com/Fortran-FOSS-Prog...ment-320093628

[Gerry Kan]

Grazie Paolo.

I suspected as much; these two lines do nothing and, since they don't do anything, they got left behind. What I find strange is that these two lines are present in every module in the code base. I guess it's the result of copy and paste operations.

Sometimes I think the additional verbosity introduced in F90 do not serve to impose better coding discipline.

Gerry.

[sbaffini]

Apparently there was, indeed, a gray area until F2003, for what concerns SAVE. But, as a matter of fact, no compiler vendor was able to actually implement module variables differently, because the scope of a module is kind of a beast in its own, and would have been complex (but without no advantage at all) to do anything different from using the implicit SAVE attribute on all variables.

For PRIVATE, it is more relevant if you actually use an OO approach, but I typically use it in this form:

PRIVATE
PUBLIC :: x, y, z

Mostly as a mean to avoid polluting the invoking piece of code with multiple names. But as long as the list of PUBLIC things goes above few of them, it is a signal for me to rework things better

[Gerry Kan]

Come to think of it, I think they are kind of necessary

1) The SAVE keyword means everything will retain their value when the variable in the module returns to scope. I think a lot of compiler vendors makes this default behavior, but having this will ensure consistent behavior across all modules

2) The PRIVATE keyword will, like you said, render the variables inaccessible outside of the module, except for those covered under the PUBLIC keyword. This helps encapsulate the contents of the module.

I guess the way to interpret it is that
(a) all non-public attributes are only accessible through its own module, due to the PRIVATE keyword, but
(b) the SAVE keyword will ensure the attributes retain their values upon reentry into the module

Is my understanding correct?

Gerry.

[sbaffini]

Originally Posted by Gerry Kan

Come to think of it, I think they are kind of necessary

1) The SAVE keyword means everything will retain their value when the variable in the module returns to scope. I think a lot of compiler vendors makes this default behavior, but having this will ensure consistent behavior across all modules

2) The PRIVATE keyword will, like you said, render the variables inaccessible outside of the module, except for those covered under the PUBLIC keyword. This helps encapsulate the contents of the module.

I guess the way to interpret it is that
(a) all non-public attributes are only accessible through its own module, due to the PRIVATE keyword, but
(b) the SAVE keyword will ensure the attributes retain their values upon reentry into the module

Is my understanding correct?

Ed.

Yes but, again, the SAVE attribute has been made ininfluent for variables defined within the scope of the whole module. Compiler vendors found out that there was no other meaningful way to treat them except for assuming SAVE in all the cases.

Because, if you don't care of the value you don't care if it is the last one as well.

Any other possible use of variables with whole module scope I can think of is very bad programming (even just because it was relying on some uncertain part of the standard before it changed).

So, we basically save a line for each module, which is nice

[Gerry Kan]

Paolo:

So based on what you said: PRIVATE good, SAVE bad. I will do that.

Gerry.