Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29004 Discussions

Getting rid of !DEC$ annotations with ISO_C_BINDING

joseph-krahn
New Contributor I
538 Views
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.
0 Kudos
6 Replies
Steven_L_Intel1
Employee
538 Views
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.)
0 Kudos
garylscott1
Beginner
538 Views
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).
0 Kudos
jimdempseyatthecove
Honored Contributor III
538 Views

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

0 Kudos
garylscott1
Beginner
538 Views

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.

0 Kudos
Steven_L_Intel1
Employee
538 Views
The compiler does support those methods. The Fortran standard syntax you want to use does not. Use the compiler extensions instead.
0 Kudos
joseph-krahn
New Contributor I
538 Views
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.
0 Kudos
Reply