Derived type containing pointer elements

[netphilou31]

Hi all,

I have a derived type that contains pointer elements (like real(8), pointer :: A(:)). There are several of these elements in my type (which also has the sequence attribute) and I need to share this data type with a Delphi application. The Delphi application has its own derived type that match mine and I pass the address of my derived type to the Delphi application. Unfortunately, it seems that there is some gap between the pointer element and the next element in the derived type (an offset of 26 bytes if I am right). I guess that this information is related to the allocated memory bloc associated with the pointer in the case where the pointer is being allocated (not associated) but I need more information to pass to the Delphi programmer especially in order to know what happens when switching to 64-bits.

Best regards,

[Steven_L_Intel1]

It's not a gap, but the rest of the descriptor for the pointer. You want to use TYPE(C_PTR) from ISO_C_BINDING instead if you want to share with non-Fortran code. Use C_F_POINTER and C_LOC to cast back and forth from Fortran pointers.

[netphilou31]

Hi Steve and thanks for the quick reply.

If I understand correctly, do I mean that I have to replace my typed pointer by an integer pointer. But unfortunately, my derived type is used as an array so it is an array of derived type containing typed pointers. Do you have any information about the structure of the pointer descriptor ?

Best regards,

Phil.

[Steven_L_Intel1]

Not an "integer pointer", a component of type C_PTR. (Yes, it is just an address.)  An array of these is fine. Typically you'd declare a local pointer of the normal type and use C_F_POINTER to convert the C_PTR to a Fortran pointer (and then use C_LOC to fill in the type component.)

We do document the layout of descriptors as long as you're not using CLASS - it's in the mixed-language programming section of the documentation. But I want to STRONGLY discourage you from doing this. Please use C_PTR instead.

[netphilou31]

Hi Steve,

Thanks for the clarification.

However I am currently still using CVF (even if we are planning to migrate to IVF very shortly) and I will not be able to use the ISO_C_BINDING module nor the specific derived types. Furthermore, as mentionned previously the derived type that contains the pointer components is itself an array, so if I want to use C_PTR types, I will have to declare many different arrays and cast them to the C_PTR component. Is it the same for components that have the allocatable attribute ? (I think that the standard allows that now).

Phil

[Steven_L_Intel1]

Yes, components with the ALLOCATABLE attribute also have descriptors. What's more, the CVF descriptor is not the same as the Intel Fortran descriptor and is of a different length. You're just going to make it difficult for yourself if you try to use the descriptor layout in the other language.

[netphilou31]

Thanks Steve,

You are right, I have browsed the documentation and it appears that CVF Fortran descriptor is effectively different (with IVF an array of rank 1 needs 35 bytes and it seems that 26 bytes only are required for CVF). I will try to manage this and if not possible I will probably have to switch to static allocations even if it is more memory consuming (I have browsed other projects we have and that communicate with Delphi IHMs and when We had to pass arrays as types components we have used static allocation).

Best regards,

Phil.