On Oct 9, 2005, at 11:06 PM, David Vowles wrote:
[code elided. It has an allocatable component of a nonsaved local
variable]
> Is the allocatable component XX%A in MYSUB automatically deallocated
> upon return from this subroutine?
> (I understand that YY in the above subroutine is automatically
> deallocated.)
Short answer. Yes.
Slightly longer answer. You can count on the fact that allocatable
variables *always* get deallocated at the "appropriate" times. The
"appropriate" bit is admittedly hard to figure out on occasion, but in
any case, you can be sure that either the variable stays allocated and
defined or it becomes deallocated. There is one case (not this one - it
involves module variables) where it is processor-dependent which
happens, but it will still be one or the other and you can test with
the allocated intrinsic. F90 was different - horribly so, but this got
fixed in f95. A fundamental result is that it is impossible to leak
memory because of programmer errors in f95 (or f2003) code. Compiler
bugs are another matter.
Language lawyer answer. I realize that this stuff is often buried in
strange hard-to-find places. I'm actually having a little trouble
finding exactly the right quote for this case, but I did find adequate
supporting material, even if a bit indirect. See the penultimate para
of 6.3.1.1
"An unsaved allocatable object that is a local variable of a
procedure has a status of unallocated
at the beginning of each invocation of the procedure."
Note that, unlike the quote in 6.3.3.1, this is not restricted to named
variables. The component in question is a local variable of the
procedure, even if not a named one. If you had any doubt about that,
see the last sentence of 2.4.3.1.1
"A subobject of a named local variable is also a local variable."
What I haven't yet found is anything to explicitly say exactly when the
variable becomes deallocated. I might possibly have missed it. One
might argue that it could become deallocated only on invocation, but I
don't think that holds up. I think the correct result (that it happens
on the return) can be proved indirectly anyway, though it would be nice
to not have to prove the theorem. Still, the theorem provides the
answer needed by the programmer; only the language lawyers need to
debate whether it ought to be stated more explicitly. In most cases,
the programmer would have a hard time telling when the deallocation
happened anyway, since the variable is out of scope during the time
period in question. But there are cases where it could be detected,
including cases where it is the target or a pointer or the derived type
has a final procedure. (Though if the derived type has a final
procedure, then it is finalizable, and the answer is probably in that
section). Part of the evidence for the theorem lies in 16.5.6(3)(a),
noting again that this is not restricted to named variables.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|