Consider a derived type used thus:

type mytype
integer :: a,b,c
real :: x,y,z
real, allocatable :: mydata(:)
end type

type(mytype), allocatable :: cell(:)
type(mytype) :: acell

allocate(cell(1000))
do i = 1,1000
if (i <= 500) then
allocate(cell(i)%%mydata(10))
else
allocate(cell(i)%%mydata(100))
endif
enddo

acell = cell(100)
...
acell = cell(600)

On 29 apr, 09:57, Gib Bogle ihug.too.much.spam.co.nz> wrote:

Hi,

I don't remember exactly where I read it on this forum,
but I remember that the difference between allocatable and pointer
arrays is that, when an allocatable array goes out of scope,
it is automatically deallocated.
A pointer which goes out of scope is not automatically deallocated,
because it may happen that another pointer keeps a reference
to the pointee, so that an automatic deallocation would lost
the reference.
This is the main reason for the overhead of a allocatable
array (and is also the main reason for some bugs in the
implementation of allocatable in fortran compilers, which is
tricky in complicated situations, like derived type, recursive
function, etc...).

But what would be the size if the derived type would only contain
the array, and not the integer :

type cell_data
integer, allocatable, dimension(:) :: mydata
end type cell_data

relaxmike gmail.com> wrote:

That is *A* difference. It is certainly not *THE* difference.

No. That has pretty much nothing to do with it. Indeed, the size
overhead of an alocatable array is typically the same as that for a
pointer array.

Not typically. There can be padding in some cases.

Let me expand a bit on Richard's comment

relaxmike wrote:
| Hi,
|
| I don't remember exactly where I read it on this forum,
| but I remember that the difference between allocatable and pointer
| arrays is that, when an allocatable array goes out of scope,
| it is automatically deallocated.
| A pointer which goes out of scope is not automatically deallocated,
| because it may happen that another pointer keeps a reference
| to the pointee, so that an automatic deallocation would lost
| the reference.
| This is the main reason for the overhead of a allocatable
| array (and is also the main reason for some bugs in the
| implementation of allocatable in fortran compilers, which is
| tricky in complicated situations, like derived type, recursive
| function, etc...).

On 29 avr, 11:26, nos...@see.signature (Richard Maine) wrote:

Despite appearances, I think that we do not disagree that much !
I really do not understand what happens internally in the
compilers, so I experimented a little bit, with the gfortran
compiler and the -fdump-tree-original option, which generates
an intermediate code, before the creation of the final executable.
I used the following source code :

program extra_mem
integer, allocatable, dimension(:) :: mydata
allocate ( mydata ( 10 ))
deallocate ( mydata )
end program

relaxmike wrote:
| On 29 avr, 11:26, nos...@see.signature (Richard Maine) wrote:
|| That is *A* difference. It is certainly not *THE* difference. [...]
|| No. [...]
|| Not typically. [...]
|| No. [...]
|
| Despite appearances, I think that we do not disagree that much !

| This is an abstract :
|
| extra_mem ()
| {
| struct array1_integer(kind=4) mydata;
| static integer(kind=4) options.0[7] = {68, 255, 0, 0, 0, 1, 0};
| mydata.data = 0B;
| _gfortran_set_options (7, (void *) &options.0);
| {
| void * D.567;
| mydata.dtype = 265; ...

The gfortran implementation of allocatable components attempts to
realise the extension to F95, TR15581: ftp://ftp.nag.co.uk/sc22wg5/N1351-N1400/N1379.pdf

Amongst other things, automatic memory deallocation/allocation on
assignment or with derived type constructors, automatic deallocation
on leaving scope and MOVE_ALLOC are implemented. In principle, memory
leakage should be prevented automatically. In practice, gfortran does
not quite manage this in the case of nested constructors but seems to
do OK otherwise. I am working on this and related issues and expect
to fix it soon.

Regards

Paul Thomas

On 29 avr, 14:08, "Jugoslav Dujic" yahoo.com> wrote:

Now I understand that this is not english, it is fortran...

relaxmike gmail.com> wrote:

That term in Fortran at least has recognizable analogy with the English.
The analogy might be a little easier to recognize if stated in a
different way. Jugoslav gave a definition in terms of syntax, which
doesnt capture the analogy well. It also doesn't catch all the cases
because it isn't actually the definition; it is just an example of the
syntax of one way to get an array with a specified stride. I'll try in
other terms that make the analogy explicit.

For the moment, I'll stick to arrays of rank 1. For higher ranks, the
same concept applies to each rank.

The stride is the distance (in memory) that you go in one step (between
aray elements). That definition shows the analogy.