- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm trying to implement an array of pointers using derived data
types in the following way
program:
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
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
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Thanks.
Gustavo.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks guys.
I promise start reading the documentation more carefully before asking here.
Gustavo
I promise start reading the documentation more carefully before asking here.
Gustavo
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page