The size in bytes of an array of pointers

[Gustavo_Colvero]

Hi,

I'm trying to implement an array of pointers using derived data
types in the following way

[fortran]program test

  implicit none

  type :: ptrs
    double precision, dimension(:), pointer :: ptr => null()
  end type

  type :: ptr_table
    type(ptrs), dimension(10) :: cols
  end type

  type(ptr_table) :: tab

  WRITE(*,*)sizeof(tab%cols)
  WRITE(*,*)sizeof(tab%cols(1))
  WRITE(*,*)sizeof(tab%cols(1)%ptr)

end program[/fortran]

I got lost here because of the output of this piece of
program:

[fortran]720
72
0[/fortran]

Is this code allocating the size of 9 doubles for each element
col? Aren't they null pointers? And why 9 doubles?

Am I producing garbage here?

Thanks.


PS: Sorry if I'm missing something trivial.
PS2: compiling with gfortran I have the output 480, 48, 8

[Steven_L_Intel1]

An array pointer is much more than an address - it has bounds and stride info as well. Your last WRITE is invalid because it is asking for the size of an unassociated pointer.

[Gustavo_Colvero]

Thanks for answering.

When you say

Your last WRITE is invalid because it is asking for the size of an unassociated pointer.

I agree. In fact this was the only output I was expecting.

Writing

[fortran]TYPE(ptrs) :: col
...
WRITE(*,*)sizeof(col)[/fortran]

I get 72, so I learned that 72 bytes is the size of an object of type ptr no matter the status of the pointer.

Each extra dimension in ptr adds 24 bytes to the object.

An array pointer is much more than an address - it has bounds and stride info as well.

Is this is the source of the starting 72 bytes for an object of type ptr and extra 24 bytes for each extra
dimension in the declared pointer?

When I declare

[fortran]DOUBLE PRECISION, DIMENSION(:), POINTER :: ptr => NULL()[/fortran]

is 72 bytes being reserved somewhere? I'm just curious about this.


Thanks.
Gustavo.

[mecej4]

The object size is compiler-dependent. In fact, the IFort-IA32 compiler will give different answers: 360, 36 and 0. The size may change after you associate the pointers with some objects.

As Steve wrote, the compiler may store information regarding an object that is not visible to the Fortran programmer. You may ask the compiler to save the assembly output.

[Steven_L_Intel1]

The layout of an array descriptor is documented in the Building Applications > Mixed Language Programming section, though not as clearly as I would like.

Every array has a base address, "A0 address" (helpful in computing an element address), element length, number of dimensions and flags indicating various states (allocated, defined, not deallocatable, etc.). All fields are "address-sized integers". Then for each dimension there is a lower bound, upper bound and stride.

[jimdempseyatthecove]

Quoting Steve Lionel (Intel)

The layout of an array descriptor is documented in the Building Applications > Mixed Language Programming section, though not as clearly as I would like.

Every array has a base address, "A0 address" (helpful in computing an element address), element length, number of dimensions and flags indicating various states (allocated, defined, not deallocatable, etc.). All fields are "address-sized integers". Then for each dimension there is a lower bound, upper bound and stride.

Also note, Steve is saying the "A0 address". For the majority of FORTRAN arrays, which are 1-based indexed, the A0 addresss points to one element _before_ the allocated memory. IOW the hypothetical 0'th entry of an array allocated (1:n). The reasoning for this is an optimization issue whereby you do not have to subtract the offset to the base of the array. Note, for array allocated (5:n) the pointer points to the hypothetical 0'th entry. Or -5 elements before allocated memory.

Jim Dempsey

[Gustavo_Colvero]

Thanks guys.

I promise start reading the documentation more carefully before asking here.

Gustavo