Allocatable components of function result
leonardoce
In the Fortran 95 TR-15581 I've read that the allocatable components
of a function result should be deallocated automatically after the
result has been used. But running the following program:
program test
implicit none
type tderivedtest
integer :: flag
integer, dimension(:), allocatable :: vect
end type tderivedtest
type(tderivedtest) :: v1
v1=functionTest()
contains
function functionTest()
type(tderivedtest) :: functionTest
allocate(functionTest%vect(1:1000))
functionTest%flag=1
end function functionTest
end program test
I obtain:
Remaining memory: 4000 bytes at 004b40b8 allocated at line 14 of
test.f90
(The memory leak detector is a wonderful feature!)
Probably I haven't understood correctly the TR.... or there is a bug?
I tried on Windows and on Linux obtaining the same behaviour.
The "g95 -dumpversion" output is:
G95 (GCC 4.0.4 (g95 0.92!) Sep 16 2008)
Copyright (C) 2002-2005 Free Software Foundation, Inc.
Where I'm wrong?
Thanks,
Leonardo
Evangelos Bertakis
If you use strict Fortran 95 syntax checking by compiling with
-std=f95 you get the following error:
integer, dimension(:), allocatable :: vect
1
Error: ALLOCATABLE attribute at (1) is not allowed in a TYPE definition
In file a.f95:11
Vangelis
Leonardo Cecchi
Does this means that allocatable structure components (TR 15581)
aren't supported by G95 or that I haven't used them correctly?
The example that is reported in the Technical Report draft contains
something like this:
TYPE REAL_POLYNOMIAL
REAL, ALLOCATABLE :: COEFF(:)
END TYPE
If I compile that example with the -std=f95 option I obtain the same
compilation error.
Thanks for the reply,
Leonardo
Udo Grabowski
> In the Fortran 95 TR-15581 I've read that the allocatable components
> of a function result should be deallocated automatically after the
> result has been used.
> program test
> implicit none
>
> type tderivedtest
> integer :: flag
> integer, dimension(:), allocatable :: vect
> end type tderivedtest
>
> type(tderivedtest) :: v1
> v1=functionTest()
> contains
> function functionTest()
> type(tderivedtest) :: functionTest
> allocate(functionTest%vect(1:1000))
> functionTest%flag=1
> end function functionTest
> end program test
> ...
>
> Remaining memory: 4000 bytes at 004b40b8 allocated at line 14 of
> test.f90
> ...
> Probably I haven't understood correctly the TR.... or there is a bug?
It's only a Technical Recommendation, so the compiler vendor is not obliged
to implement it, although it should be done correctly if done at all.
The TR reads:
"Any allocated allocatable components of a function
result are automatically deallocated after the result has been used."
"Intrinsic assignment of such types does a "deep copy" of the allocatable array
components; it is as if the allocatable array component were deallocated (if
necessary), then if the component in the expression was allocated, the
variable's component is allocated to the right size and the value copied.
So assigning the function result to a variable should do a deep
copy with automatic allocation of the variables allocatable components,
and then deallocate the functions result memory."
And here is the clue: Since you are assigning the result to a variable v1,
it's allocatable elements are allocated as the result of the assignment, and
the results elements of the functions are correctly deallocated (otherwise
it would show 8000 bytes instead of 4000 bytes). If the elements of v1 were
deallocated instead, you couldn't use it, could you ?
So everything here works as expected :-)
--
Dr. Udo Grabowski email: udo.gr...@imk.fzk.de
Institut f. Meteorologie und Klimaforschung ASF,Forschungszentrum Karlsruhe
Postfach 3640, 76021 Karlsruhe, Germany Tel: (+49) 7247 82-6026
http://www.fzk.de/imk/asf/sat/grabowski/ Fax: " -7026
Evangelos Bertakis
> It's only a Technical Recommendation, so the compiler vendor is not obliged
> to implement it, although it should be done correctly if done at all.
Thanks for the info, I did not know that. The problem goes away if the
program above is compiled with -std=f2003. I guess that means that the
TR-15581 is now part of the Fortran 2003 standard (?).
Vangelis
Leonardo Cecchi
> it's allocatable elements are allocated as the result of the assignment, and
> the results elements of the functions are correctly deallocated (otherwise
> it would show 8000 bytes instead of 4000 bytes). If the elements of v1 were
> deallocated instead, you couldn't use it, could you ?
> So everything here works as expected :-)
Thanks for the kind response.
There is something that isn't clear to me:
1) Why the memory leak is reported for a block of memory allocated
with the "allocate" construct in the function if the function result
is correctly deallocated?
2) Why the elements of "v1" aren't automatically deallocated at the
program termination?
Thanks again,
Leonardo
Damian Rouson
Recommendation" and yes, the TR became part of the 2003 standard.
Damian