- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Windows Fortran programmers are used to all of the !DEC$ statements used to interface with C library calls. It would be nice if they could be replaced by the F2003 ISO_C_BINDING feature. It is probably not an issue for interfacing MS-Windows libraries, but all of those non-standard annotations can be a nuisance when trying to write cross-platform portable code.
One problem is that F2003 does not address non-sdtandard attributes like STDCALL, dllimport or dllexport. For DLL exports, you can give a ".def" file to the linker, which could be used to build .MOD files with approriate impot/export hints. That would avoid !DEC$ annotations at least for building a Fortran library.
For generating C interface files, why not just have a single "STDCALL, DLLIMPORT" hint at the beginning and end of the file, instead of requiring it for every interface? For a given header/include file, they are usually all the same.
One problem is that F2003 does not address non-sdtandard attributes like STDCALL, dllimport or dllexport. For DLL exports, you can give a ".def" file to the linker, which could be used to build .MOD files with approriate impot/export hints. That would avoid !DEC$ annotations at least for building a Fortran library.
For generating C interface files, why not just have a single "STDCALL, DLLIMPORT" hint at the beginning and end of the file, instead of requiring it for every interface? For a given header/include file, they are usually all the same.
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't see how you can avoid "non-standard annotations" when writing non-standard code. If you are building your own library, why use STDCALL at all? Even if attributes such as STDCALL and DLLEXPORT were added to BIND, the code would STILL be non-portable. Conditional compilation is your friend here (still non-standard, but very portable.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, STDCALL is called STDCALL because it was once the standard call mechanism on Windows. There are lots of 3rd party libraries out there that I interface with that use it. Isn'tSTDCALL sort of like saying "BIND(PASCAL)" (which was the language ofa lot of the old windows API).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Gary,
When compiling for x64 (EM64T) you do not use STDCALL. So it is no longer _the_ standard call for Windows... Windows x32 - yes, Windowsx64 no.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've read that before. Was this thread about X64? Sorry. Still, the compiler should maintain the flexibility to support multiple calling conventions if those alternate methods provide some advantage, especially in the area of execution performance. Just because MS C chooses a particular method doesn't mean that's the only one that is desirable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The compiler does support those methods. The Fortran standard syntax you want to use does not. Use the compiler extensions instead.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Obviously, the main problem is that most compilers have non-standard extensions, and F2003 chose only to address standard-conforming C calls. Extending BIND() would only work if the standard had explicitly supported it. So, I agree that there really is no completely portable solution.
However, there are ways around the DLL import/export attribute. For example, there could be a compiler flag that says to "dllexport" all public functions in the source file. To deal with DLL imports, binary .mod files can be stored in the link library, and modules accessed that way could automatically use the dllimport attribute for access.
That is probably a lot of work just for some convenience, especially since the current system already works well.
However, there are ways around the DLL import/export attribute. For example, there could be a compiler flag that says to "dllexport" all public functions in the source file. To deal with DLL imports, binary .mod files can be stored in the link library, and modules accessed that way could automatically use the dllimport attribute for access.
That is probably a lot of work just for some convenience, especially since the current system already works well.

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