deallocating pointer components of a derived type and the type itself

[YertleTheTurtle]

If a derived type has pointer components, it is convenient to have a service routine to deallocate them.

It is (should be) also convenient to deallocate the derived type object itself. In the example given below, the intent is to deallocate all components of VMESHTYPE, as well as VMESHTYPE itself. Two compilers (Intel included) accept this, a third doesn't claiming that a dummy variable isn't allowed to have the ALLOCATABLE attribute. I checked, and that is what my book says too (Metcalf and Reid, page 147).

So, is this really allowed or not, and if not, why does the Intel compiler accept this?

If it is not allowed, is there any way to collect the final Deallocate statement in one place (e.g. Vkill routine), without having to spread it throughout the code for each of the derived objects at Deallocation time?

----------------file fill.f90 ------------------------

module fill
TYPE mesh
integer :: nray
REAL(kind=4) :: dirn
INTEGER, DIMENSION(:), pointer :: nbod
END type
end module fill

------------------------ file vkill.f90 ------------------

subroutine vkill(vMeshType)

USE fill, ONLY : mesh
implicit none
! Is "ALLOCATABLE" allowed in the next statement?

TYPE(mesh), INTENT(inout), ALLOCATABLE, DIMENSION(:,:) :: vmeshType

INTEGER, DIMENSION(2) :: J1, J2
INTEGER :: jx, jy, ier, nray
!
! This subroutine works through and deallocates all the components of the "mesh" type array vMeshType
!
j1 = LBOUND(VMeshType)
J2 = UBOUND(VMeshType)

do jx = j1(1), j2(1)
do jy = j1(2), j2(2)
nray = vMeshType(jx,jy)%nray
if (nray.gt.1) then
DEALLOCATE(vMeshType(jx,jy)%nbod,stat=ier)
end if
end do
end do

DEALLOCATE(VMeshType) ! This statement is the source of the problem!!!

return
end subroutine vkill

[Xiaoping_D_Intel]

ALLOCATABLE attribute is allowed for a dummy argument by Intel compiler. Once a dummy argument is allocatable, the actual argument must be allocatable and the type parameters and ranks must agree.

At the end of "FUNCTION" statement reference in Intel Fortran Language Reference document there is an example of an allocatable function with allocatable arrays.

[Jugoslav_Dujic]

Quoting YertleTheTurtle

It is (should be) also convenient to deallocate the derived type object itself. In the example given below, the intent is to deallocate all components of VMESHTYPE, as well as VMESHTYPE itself. Two compilers (Intel included) accept this, a third doesn't claiming that a dummy variable isn't allowed to have the ALLOCATABLE attribute. I checked, and that is what my book says too (Metcalf and Reid, page 147).

So, is this really allowed or not, and if not, why does the Intel compiler accept this?

Well, your book is outdated: allocatable dummies, function results, and derived type components were introduced to the language some time around 1998, in an "official standard extension" called TR15581. Your example is one of the very reasons why it was introduced so quickly, even before the subsequent standard (Fortran 2003): the original F95 support for allocatables was rather crippled and pointers -- the workaround -- are much more error-prone. By now, it is implemented in all compilers and virtually bug-free.

Further, Intel Fortran aims for full Fortran 2003 compatibility, and by now has some 80-90% of it implemented. Unfortunately, the documentation is missing in current 11.1 version. For a good overview of F2003 features, see this John Reid's paper (yes, that same Reid).

[Steven_L_Intel1]

ALLOCATABLE dummy arguments are indeed permitted - as noted, this is a Fortran 2003 feature we have supported for many years. When you deallocate an ALLOCATABLE variable of derived type, all ALLOCATABLE subcomponents are automatically deallocated. This does NOT hold for POINTER, however. So in your example, you must still explicitly deallocate the POINTER components of the derived type - the single DEALLOCATE at the end won't do. Of course, if you made the components ALLOCATABLE (another F2003 feature supporteed), then the single DEALLOCATE would be fine.

[YertleTheTurtle]

Thank you all for your helpful answers.

A further question for Steve. You wrote:

"Of course, if you made the components A LLOCATABLE (another F2003 feature supporteed), then the single DEALLOCATE would be fine."

Were you referring to ALL the components (including the garden variety INTEGERS/REALS) or just the ones that are pointers in the example.

Nothing can have both "pointer" and "allocatable" attributes simultaneously, so presumably you were saying that pointers should be changed to allocatable components in the example. Is that correct?

[Steven_L_Intel1]

Right - I meant that if you changed the POINTERs to ALLOCATABLE.