derived type with allocatable components

[filav]

Hello,
I'm trying to use structured variable with allocatable components (beginner in this area). I have doubt aboutfree upmemory.Could somebody help me to explainwhen I need to deallocate the array by myself. I put short sample of code for illustration.

1) I'm allocating local array inside the subroutine or function.I suppose that the local arrays allocatedare clean(deallocated) automatically on exit from procedure ifthey don't have the attribute save. It is right?

2) Type Struct contains allocatable array S of type S1. The type S1 also contains allocatablearray of real (see please sample code). WhenI deallocate the array inside the structure Struct.What happenswith allocated array inside the structure S1? Is the memorycleaned automatically or the array is wasting there? Should I deallocate firstly all arrays in S1 and then in Struct?

Type(struct) :: Mobj
.....
deallocate(Mobj.s) ?? it is enough

3) I have eg.functionModifyObject_1 modifying some template object and creating new modified object ( see please the sample code). I'm using Move_alloc procedure for changing the array inside the Struct which should save time and should clean the allocated array. It is OK?

4)What happens with allocated memory for Mobj when I try to write following statement in my code

Mobj=ModifyObject(Mobj,Seg)

It is memory free automatically orI should deallocate arrays inMobjinside function?

5) The last situation not clear for me. What happens in the case when I have eg. two variables

type (Struct) :: Mobj1,Mobj2

I allocated arrays insideMobj1 and Mobj2 (havingdifferent dimension I think not important)and now I will write statement Mobj1=Mobj2. I hope that the compiler solving this and the initially allocated array in Mobj1 are deallocated andI don't need to do it by myself.It is right?


Thank you in advance for your comments and remarks.

Vlastimil






Sample code:
========
module testMod
type S1
integer :: Nx=0
real*8,allocatable :: X(:)
!...... more components
end type

type Struct
integer :: ns=0
type(s1), allocatable :: s(:)
! ...... more components
end type

interface ModifyObject
module procedure ModifyObject_1
end interface
contains

function ModifyObject_1 (obj, s) result(obj1)
implicit none
type(struct), intent(in) :: obj
type(S1), intent(in) :: s
type(struct) :: obj1
type(S1),allocatable :: SA(:)
allocate(SA(obj.ns+1))
Obj1=Obj
if (Obj%Ns>0) SA(:Obj%Ns)=Obj%s(:Obj%Ns)
call Move_alloc(SA,obj1%s)
Obj1%Ns=Obj%Ns+1
end function

end module

! --------------------- test program ----------
! test samples
use testMod
implicit none
Type(struct):: MObj, Mobj1
type(S1), allocatable :: Seg
integer :: Nx
Nx=5
allocate(Seg%X(Nx))

Seg%X=1d0
Seg%Nx=Nx

Mobj1=ModifyObject(Mobj,Seg)

end

[Steven_L_Intel1]

1) Right - any non-SAVE local allocatable variables are automatically deallocated on routine exit.

2) When you deallocate an object of derived type, all allocatable subobjects are automatically deallocated

3) I'm not sure what you mean by "clean", but I don't see a problem with your code.

4) The compiler should take care of deallocating the function result after the assignment.

5) Right. When you assign objects of derived type, any allocatable components on the left side get automatically (re)allocated to match the shape of the corresponding right side. Note that this also applies to allocatable arrays NOT of derived type, but only if you use the option /assume:realloc_lhs. That option is not required for the derived type case.

[joseph-krahn]

Here is how I think about allocatble objects in Fortran. F2003 and F2008 have more features for object-oriented programming, so it is good to have a general understanding of constructors and destructors handled by the compiler. (See Steve's post for specific answers.)

An allocatable array works a lot like a C++ object with a constructor and a destructor (as of F2003 or F95 with TR 15581). If you have not programmed in C++ (or another object-oriented language), it seems kind of magic. When an object is destroyed, the destructors of all of it's contained objects are destroyed. When an object is created, it has a constructor to initialize the object. The compiler will invoke these constructor and destructor procedures automatically for objects that are created or destroyed at the beginning and end of a routine. For allocatables, these routines are all internal to the compiler.

In general, memory management of allocatables makes it essentially impossible to leak memory, although you could have unused SAVEd arrays that are still allocated. This is not the case for pointers. They are not automatically deallocated when the pointer itself goes of of scope, including pointers that are sub-objects of an allocated type.

[Steven_L_Intel1]

Nice explanation!