Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>In principal when a module goes out-of-scope, the variables of that module become undefined -- unless they are declared with the SAVE attribute, or a SAVE statement is used. "Undefined" means that you are not allowed to rely on the variable having the previous value if you again use the module -- it might have the previous value when you re-access the module, or it might not -- there is no guarantee. But many compilers don't do this for <em>module</em> variables -- the variables probably retain their values -- it isn't worth the effort for the compiler to figure out whether a module remains in scope or not and probably module variables are treated as global variables -- but don't rely on that! To be safe, either use "save" or "use" the module from the main program so that it never goes out of scope.</p> <p>"save" is also important in procedures, to store "state" across invocations of the subroutine or function (as written by @ire_and_curses) -- "first invocation" initializations, counters, etc.</p> <pre><code>subroutine my_sub (y) integer :: var integer, save :: counter = 0 logical, save :: FirstCall = .TRUE. counter = counter + 1 write (*, *) counter if (FirstCall) then FirstCall = .FALSE. .... end if var = .... </code></pre> <p>etc.</p> <p>In this code fragment, "counter" will report the number of invocations of subroutine x. Though actually in Fortran >=90 one can omit the "save" because the initialization in the declaration implies "save".</p> <p>In contrast to the module case, with modern compilers, without the save attribute or initialization-on-a-declaration, it is normal for local variables of procedures to lose their values across invocations. So if you attempt to use "var" on an later call before redefining it in that call, the value is undefined and probably won't be the value calculated on a previous invocation of the procedure.</p> <p>This is different from the behavior of many FORTRAN 77 compilers, some of which retained the values of all local variables, even though this wasn't required by the language standard. Some old programs were written relying on this non-standard behavior -- these programs will fail on the newer compilers. Many compilers have an option to use the non-standard behavior and "save" all local variables.</p> <p>LATER EDIT: update with a code example that shows <strong>incorrect</strong> usage of a local variable that should have the save attribute but doesn't:</p> <pre><code>module subs contains subroutine asub (i, control) implicit none integer, intent (in) :: i logical, intent (in) :: control integer, save :: j = 0 integer :: k j = j + i if ( control ) k = 0 k = k + i write (*, *) 'i, j, k=', i, j, k end subroutine asub end module subs program test_saves use subs implicit none call asub ( 3, .TRUE. ) call asub ( 4, .FALSE. ) end program test_saves </code></pre> <p>Local variable <em>k</em> of the subroutine is intentionally misused -- in this program it is initialized in the first call since <em>control</em> is TRUE, but on the second call <em>control</em> is FALSE, so <em>k</em> is not redefined. But without the save attribute <em>k</em> is undefined, so the using its value is illegal.</p> <p>Compiling the program with gfortran, I found that <em>k</em> retained its value anyway:</p> <pre><code> i, j, k= 3 3 3 i, j, k= 4 7 7 </code></pre> <p>Compiling the program with ifort and aggressive optimization options, k lost its value:</p> <pre><code> i, j, k= 3 3 3 i, j, k= 4 7 4 </code></pre> <p>Using ifort with debugging options, the problems was detected at runtime!</p> <pre><code> i, j, k= 3 3 3 forrtl: severe (193): Run-Time Check Failure. The variable 'subs_mp_asub_$K' is being used without being defined </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POFortran SAVE statement
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USM. S. B.
    1. USM. S. B.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POFortran SAVE statement
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload