- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a C++ header file from an third-party SDK that I want to interface to in FORTRAN. I think I can handle writing the SUBROUTINE and FUNCTION interfaces, but what about typedefs? Typedefs thtat point to other typedefs? Enumerations? #ifdef? #ifndef? #define? Is there any documentation on this?
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm afraid you're pretty much on your own here. I can offer only few general tips:
- All typedefs (and #defines for type names) should be reduced to basic fortran types (INTEGER(x), REAL, LOGICAL, CHARACTER) following the path to the basic typedef (e.g. typedef int MYINT) Enumerations are integer(4) by C++ standard...
- ...except, of course, derived types (structs)
- Calling convention should be adjusted; you should specify !DEC$ATTRIBUTES C or STDCALL depending on how functions are declared in C header file. Note that CVF does not support __fastcall, which is default for VC++.
- You should always specify ALIAS attribute for functions, specifying the exact mangled name as exported from DLL or lib.
- #ifdefs can be emulated with !DEC$IF DEFINED / !DEC$ELSE / !DEC$ENDIF. Note, however, that it makes sense only for user-defined symbols. "Standard" C compiler symbols (such as _UNICODE, __cplusplus, _DEBUG) will not be automatically defined by CVF. Usually, simply don't translate #ifdef blocks you don't need (say, UNICODE).
- Take care about pointer (*) or reference (&) arguments or their typedefs (typically Pxxxx or LPxxxx). Such function arguments should have !DEC$ATTRIBUTES REFERENCE. Especially, all strings (char*) should have REFERENCE attribute
- It's a good idea to have two modules, one with constant and type declarations and other containing only INTERFACEs using the first. Moreover, you have to do it if any function accepts derived type as an argument (because of scoping of interface blocks).
I suggest you take some short Win32 header module from .../DF/Include and compare it against the corresponding C header file (or, if you don't have any, with C declarations in Win32 API). I think you'll get a rather good idea about techniques used.
Regards
Jugoslav
- All typedefs (and #defines for type names) should be reduced to basic fortran types (INTEGER(x), REAL, LOGICAL, CHARACTER) following the path to the basic typedef (e.g. typedef int MYINT) Enumerations are integer(4) by C++ standard...
- ...except, of course, derived types (structs)
- Calling convention should be adjusted; you should specify !DEC$ATTRIBUTES C or STDCALL depending on how functions are declared in C header file. Note that CVF does not support __fastcall, which is default for VC++.
- You should always specify ALIAS attribute for functions, specifying the exact mangled name as exported from DLL or lib.
- #ifdefs can be emulated with !DEC$IF DEFINED / !DEC$ELSE / !DEC$ENDIF. Note, however, that it makes sense only for user-defined symbols. "Standard" C compiler symbols (such as _UNICODE, __cplusplus, _DEBUG) will not be automatically defined by CVF. Usually, simply don't translate #ifdef blocks you don't need (say, UNICODE).
- Take care about pointer (*) or reference (&) arguments or their typedefs (typically Pxxxx or LPxxxx). Such function arguments should have !DEC$ATTRIBUTES REFERENCE. Especially, all strings (char*) should have REFERENCE attribute
- It's a good idea to have two modules, one with constant and type declarations and other containing only INTERFACEs using the first. Moreover, you have to do it if any function accepts derived type as an argument (because of scoping of interface blocks).
I suggest you take some short Win32 header module from .../DF/Include and compare it against the corresponding C header file (or, if you don't have any, with C declarations in Win32 API). I think you'll get a rather good idea about techniques used.
Regards
Jugoslav
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yikes! I would have thought Compaq could come up with something to automate this a little (like the module wizard). I think I might just see if the owners of the SDK want to do it....Thanks anyway Jugoslav
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Actually, there is a translating tool developed recently (Win32 headers in CVF 6.6 were translated using it), but it's not publicly available. Try contacting vf_support@compaq.com -- perhaps they could translate it for you. Steve?
Jugoslav
Jugoslav
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The translation tool we have was written for the specific purpose of creating DFWIN and friends - and it embeds a lot of assumptions about this environment, including the limitations in the original MS declarations. I don't think it's suitable for general use.
Steve
Steve

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page