(j3.2006) (SC22WG5.3968) question about deallocation

Malcolm Cohen malcolm
Sun Mar 29 20:30:40 EDT 2009

Robert Corbett wrote:
> Consider the code fragment
>        MODULE M
>          . . .
>          TYPE BASE
>            INTEGER I
>          CONTAINS
>            FINAL SUBR1
>          END TYPE
>          CONTAINS
>            FINAL SUBR2
>          END TYPE
>          . . .
>        END MODULE
>          USE M
>          TYPE(BASE), POINTER :: Q
>          . . .
>          ALLOCATE(P)
>          Q => P%BASE
>          . . .
>          DEALLOCATE(Q)
>          . . .
>        END
> Is the DEALLOCATE statement standard conforming?

Q is not associated with the whole of the object allocated by P, but 
only the "base" component thereof.

The answers that indicate otherwise are mistaken.  Whether EXTENDED 
takes up more memory than BASE in some/most/all implementations is not 
relevant to the question.  BASE is a part of EXTENDED, not the whole.  
It is certainly not prohibited for some implementation to actually have 
EXTENDED objects taking up more space than BASE (whether it is sensible 
is another matter).

>       ALLOCATE(P(1))
>       Q => P(1)
>       DEALLOCATE(Q) 

Did we *really* say that in an official interpretation?  Which one?  
Assuming we did, I share your disquiet about the overly simplistic reply 
to this other question, but they can be separated - if one accepts that 
arrays are just collections of elements.  It's not clear to me that 
that's a good thing to do (rather the opposite in fact), but it is not 
quite the same question.

Bill Long wrote (that it should be allowed and):
> The type of the object being deallocated is BASE, and a final routine is
> bound to the type, so I would say SUBR1 (only) is executed.
That answer is not consistent with the design of final subroutines, and 
not consistent with types.  An object of type EXTENDED was allocated.  
To deallocate an object of type EXTENDED one must deallocate an object 
of type EXTENDED - this must be fundamental to the whole idea of derived 
types.  As far as I am concerned there is no question - the program is 
not, and cannot reasonably be considered to be, standard conforming.

.......................Malcolm Cohen, Nihon NAG, Tokyo.

More information about the J3 mailing list