View previous topic :: View next topic |
Author |
Message |
jlb
Joined: 21 Oct 2020 Posts: 45
|
Posted: Thu Jan 06, 2022 6:37 pm Post subject: Interface to a DLL using derived types |
|
|
An existing module, apparently written for Intel Fortran, for interfacing to a DLL uses derived types containing only an integer as an argument for functions or procedures as well as the result of functions.
Code: | MODULE intdll
IMPLICIT NONE
TYPE dt
INTEGER i
END TYPE
INTERFACE
TYPE(dt) FUNCTION xxx(k)
!DEC$ATTRIBUTES C, DLLIMPORT, ALIAS:'_xxxA':: xxx
IMPORT
TYPE(dt) k
END FUNCTION
END INTERFACE
END MODULE intdll |
Is there a particular reason for using such a derived type?
Is there another (better) way than remplacing this derived type with an integer and suppressing the IMPORT statement when using FTN95? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Fri Jan 07, 2022 9:58 am Post subject: |
|
|
In the absence of ISO_C_BINDING all Fortran arguments are passed by reference. So the address of a TYPE argument containing only one integer member should be the same as the address of the integer.
How the function return value is processed is more problematical and might be compiler dependent.
For FTN95 it is not possible to share module data between an executable and a DLL (only module routines can be shared). This means that there is little or no motivation for using modules in this context.
Don't forget that the FTN95 code will need to use an alias for the function name otherwise it will assume the DLL uses uppercase letters.
Perhaps the only way forward is to create an Intel DLL and then look at the interfacing at the assembler level. |
|
Back to top |
|
|
jlb
Joined: 21 Oct 2020 Posts: 45
|
Posted: Tue Jan 11, 2022 2:18 pm Post subject: |
|
|
Paul
Thanks for all these explanations and advice. It helped me a lot. |
|
Back to top |
|
|
|