|
[Sponsors] |
[F90] PRIVATE and SAVE all by themselves together |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
April 21, 2021, 14:35 |
[F90] PRIVATE and SAVE all by themselves together
|
#1 |
Senior Member
Gerry Kan
Join Date: May 2016
Posts: 348
Rep Power: 10 |
Howdy Folks:
I come across this code snippit verbatim when I am editing a F90 module: Code:
! ... preceding code IMPLICIT NONE PRIVATE SAVE ! ... proceeding code Also, I thought the PRIVATE keyword has to be assigned to something in order for it to work, like Code:
! ... code before INTEGER :: X ! ... some more code in between PRIVATE X ! ... even more code afterwards Thanks in advance, Gerry. |
|
April 22, 2021, 04:06 |
|
#2 |
Senior Member
|
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. |
|
April 22, 2021, 04:14 |
|
#3 |
Senior Member
|
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
|
|
April 22, 2021, 04:53 |
|
#4 |
Senior Member
Gerry Kan
Join Date: May 2016
Posts: 348
Rep Power: 10 |
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. |
|
April 22, 2021, 05:06 |
|
#5 |
Senior Member
|
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 |
|
April 22, 2021, 06:18 |
|
#6 |
Senior Member
Gerry Kan
Join Date: May 2016
Posts: 348
Rep Power: 10 |
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. Last edited by Gerry Kan; April 22, 2021 at 08:18. |
|
April 22, 2021, 07:27 |
|
#7 | |
Senior Member
|
Quote:
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 |
||
April 22, 2021, 08:18 |
|
#8 |
Senior Member
Gerry Kan
Join Date: May 2016
Posts: 348
Rep Power: 10 |
Paolo:
So based on what you said: PRIVATE good, SAVE bad. I will do that. Gerry. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Save Reportvalue for Each Boundary in Java | CellZone | STAR-CCM+ | 0 | May 2, 2018 12:35 |