Currently, when returning a complex type to Fortran cpp_bindgen always returns bindgen_handle * as type(c_ptr) in Fortran. As a result, the actual type of the Fortran object is unknown and the user is allowed to pass the object to 'wrong' underlying C functions.
This could be improved by returning a named derived type to fortran, and requiring that type in the generated Fortran bindings. For example, consider the following generated Fortran binding:
! This file is generated!
module ghex2
implicit none
interface
type(c_ptr) function add(arg0, arg1) bind(c)
use iso_c_binding
type(c_ptr), value :: arg0
integer(c_int), value :: arg1
end function
end interface
contains
end
A binding with strong Fortran type checking could look like
! This file is generated!
module ghex2
implicit none
type, bind(c) :: vector_type
type(c_ptr) :: obj = c_null_ptr
end type vector_type
interface
type(vector_type) function add(arg0, arg1) bind(c)
use iso_c_binding
type(vector_type), value :: arg0
integer(c_int), value :: arg1
end function
end interface
contains
end
This would make the fortran interfaces compile-time type safe.
Being able to use meaningful type names instead of a generic bindgen_handle would be very useful. That is, in the above case the programmer should be able to specify the vector_type name somewhere in the C++ code, e.g., using a dedicated macro, or generic C++ capabilities.
Currently, when returning a complex type to Fortran
cpp_bindgenalways returnsbindgen_handle *astype(c_ptr)in Fortran. As a result, the actual type of the Fortran object is unknown and the user is allowed to pass the object to 'wrong' underlying C functions.This could be improved by returning a named derived type to fortran, and requiring that type in the generated Fortran bindings. For example, consider the following generated Fortran binding:
A binding with strong Fortran type checking could look like
This would make the fortran interfaces compile-time type safe.
Being able to use meaningful type names instead of a generic
bindgen_handlewould be very useful. That is, in the above case the programmer should be able to specify thevector_typename somewhere in the C++ code, e.g., using a dedicated macro, or generic C++ capabilities.