(j3.2006) allocatable function question

[Malcolm Cohen]

>
> But, in
>      x = F(y) + F(z)
> when are the results deallocated?  Assuming the processor evaluates
> F twice, how can it deallocate both after the assignment?  F must contain
> an ALLOCATE statement for its result variable.  Doesn't that mean that
> the result variable is already allocated on the second entry into F?

How is this different from a nonallocatable function; I see no real 
difference.

The result variable is local to the function, the function returns a 
value (the value the result variable has on exit), a function reference 
is not a variable.

I mean, in
   INTEGER FUNCTION F(n)
     IF (n>0) F = n
     F = F + 1
   END FUNCTION
no one seriously expects that after F(3), a reference to F(0) would 
return 4.  Well, some might indeed expect that, but it is not what the 
standard says.

> If there are actually different result variables for the two 
> invocations, then
> there is no problem; they can both be deallocated after the 
> assignment.  But,
> then why does 6.3.3.1 say things are deallocated after the innermost
> construct?  If each result is really a separate thing, there's no need 
> to specify
> when, or even if, the results are deallocated.
There most certainly is a need to specify that!  In fact that is the one 
of the main points of using allocatables and not pointers - to get 
automatic deallocation so there are no memory leaks.

(Probably we could have used a better descriptive model of how 
allocatables work to describe this, but at the time we didn't want to 
depart from the F90 model unnecessarily.  Switching to a "better" model 
would entail a moderate risk of breaking something that isn't broken, at 
least in the first round or two of edits.  Maybe next time if people 
think the existing model is deficient.)
>
> The next paragraph has a similar statement for allocatable functions
> appearing in specification statements.
And has the same purpose - to require the processor to deallocate the 
result and not just leak the memory.
>
> If there is a problem with allocatable functions, then there might be a
> similar problem for finalizable function results; the wording is 
> essentially the
> same for when functions get finalized.
I should hope so, since that is how we went about adding finalisers - 
following the existing model for allocatables.

Cheers,
-- 
................................Malcolm.