Home/ Questions/Q 9161911
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T14:05:08+00:00

In a Fortran module I have a function that takes an array and its

  • 0

In a Fortran module I have a function that takes an array and its name, gets from a database (actually calling a C function) the shape of the array, copies the array in a temporary buffer and passes the buffer to another C function that processes it. This Fortran function has the name fs_WriteData_i for integer data, fs_WriteData_f for real and fs_WriteData_d for double precision. All these functions accept not only one-dimensional arrays, but also 2D, 3D and 4D arrays and they work perfectly. Here follows the interface of one of these subroutines:

subroutine fs_WriteData_d(fieldname, data)
    use, intrinsic :: iso_c_binding
    implicit none

    real(c_double), dimension(*) :: data
    character                    :: fieldname*(*)

    ! ...

end subroutine fs_WriteData_d

If the user calls fs_WriteData_d('name', data) with data being a double precision, up to 4-dimensional array, this subroutine does the job.

Now, to the question: I want to provide a common overloaded interface called fs_WriteData, so I use

interface fs_WriteData
    module procedure fs_WriteData_i, &
                     fs_WriteData_f, &
                     fs_WriteData_d
end interface fs_WriteData

Unfortunately, this does not work: the compiler states that it cannot find the correct implementation if the user just calls fs_WriteData('name', data), and this because of a rank mismatch with all of these functions.

Is there a clever way to avoid writing all the fs_WriteData_d_1d, fs_WriteData_d_2d, … subroutines with just the same content in order to make the module more maintainable?

Many thanks in advance.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Sort of.

    As you’ve discovered, the rules for selection of a specific procedure for a generic call as of F2008 require, amongst other things and elemental procedures aside, a match of Type, Kind and Rank (so called TKR compatible). Even though the data dummy argument is assumed size (so in a direct call to a specific procedure it can be associated with an actual argument of any non-zero rank) it is still considered a rank one argument for TKR compatibility purposes.

    The recently published Technical Specification on Further Interoperability of Fortran with C (TS29113) adds the concept of assumed rank. Depending on what you do inside the executable part of fs_WriteData_d (passing to C is pretty much all that you can do) that may suit – the rules for Type/Kind/Rank matching have been extended such that assumed rank actual or dummy argument is compatible regardless of rank. The rather significant issue is then compiler support – I don’t think there are any compilers that currently support this TS!

    For coding to language standards pre-F201X there are a few possibilities:

    • Write a series of thin wrapper subroutines for each rank that you want to support, with those wrapper subroutines then calling the specific procedure for the 1D form, relying on sequence association to map the multidimensional arrays down to a 1D array.

    • Place the body of the subroutine inside a separate file, and INCLUDE that file inside skeleton interfaces for subroutines for each rank. This approach requires that the code inside the body of the subroutine be lexically rank independent. In some cases the code can also be written in a type independent manner and you can use a common include file for the various types that you want to support. While this eliminates the problems associated with change management of “copy and pasted” code, dealing with INCLUDE’d files can be a bit of a pain.

    Some combination of the two may also be suitable.

    (A third option possibly exists, to use C interoperability to set the binding name for interface bodies written for each rank and type combination to be the binding name of one implementation procedure, but I’m not sure whether that (ab)usage of C interoperability is legal.)

    If common naming for the different type variants is all you are after, then another possibility (again, depends on what you are doing in the body) is to take the data argument as a C_PTR from the ISO_C_BINDING intrinsic module and push the requirement for taking C_LOC of the actual argument back into client code of the subroutine.

    • 0