CODEWITHSUNDEEP
cpointersfortranfortran-iso-c-bindingderived-types
Stam
Stam

Reputation: 67

Fortran derived types containing derived types to be accessible from C

As an extension to this post, I have derived types which have as members derived types themselves. Example below:

module simple
use  iso_c_binding

TYPE SIMPLEF
  INTEGER :: A
  INTEGER, POINTER :: B, C(:)
END TYPE SIMPLEF

TYPE COMPLEXF
  INTEGER :: X
  TYPE (SIMPLEF) :: Y
END TYPE COMPLEXF
end module simple

The aim is, as in the post above, to have similar derived types in C and to be able to pass values back and forth to Fortran. The solution can be seen here. However here it's not just a derived type, it is a derived type with a member which is a derived type itself. Would I need to create for COMPLEXF, subroutines for each member of Y, i.e. SETY_A, QUERYY_A, SETY_B, QUERYY_BSIZE, SQUERYY_B etc.? Or is there a better way to approach this?

Upvotes: 1

Views: 354

Answers (1)

IanH
IanH

Reputation: 21431

The same approach can be used. What's best depends on what you think is the best way for your C clients to interact with your Fortran objects. Some thought should be put into this before you write too much code.

As presented, the existence of the y component is a detail that the C code probably doesn't need to care about - rather than calling the procedure sety_a you could just name it set_a.

If there are going to be many operations on the component of the COMPLEXF type and you want to avoid a level of indirection, or if there are many such components of COMPLEXF of the same type, then you can use the C address of the subobject that corresponds to that component as an opaque handle.

For the sake of example, alter the GetHandle and ReleaseHandle procedures in the linked answer to work with the COMPLEXF type as the top level type (that is - substitute COMPLEXF for all the appearances of SIMPLEF in that answer). You could then write a QueryYHandle procedure or similar, along the lines of:

FUNCTION QueryYHandle(handle) RESULT(y_handle)
  TYPE(C_PTR), INTENT(IN), VALUE :: handle
  TYPE(C_PTR) :: y_handle
  TYPE(COMPLEXF), POINTER :: p
  !***
  CALL C_F_POINTER(handle, p)
  y_handle = C_LOC(p%y)
END FUNCTION QueryYHandle

Now you can work with the handle to the SIMPLEF subobject directly - using the exact same Query*/Set* procedures as in the linked answer.

There's no need to write a procedure to deallocate the object nominated by the y_handle in this case, because the lifetime of the subobject associated with the y component is determined by the lifetime of the object that has that subobject - that subobject will go away when ReleaseHandle for the COMPLEXF super-object is called.

Note that there are no protections in the approach, as outlined above, for the wrong sort of handle to be passed between languages (for example - if the C code accidentally called a procedure intended to work with a COMPLEXF handle with a handle that was actually for a SIMPLEF object). If that is problematic then protections can be added, perhaps by bundling a handle type in with the C address in the object used as the opaque handle and checking that handle type before attempting to associate a Fortran pointer with the object nominated by the C address.

Upvotes: 2

Related Questions