Calling C++ dll from Fortran dll

[andersmathiesen]

I'm trying to call functions in a 32-bit C++ dll from a 32-bit FORTRAN dll with a userdefined TYPE as parameter, but I can't make it work. My problem is that the compilator doesn't recon the TYPE STEELDATA in this interface....

INTERFACE
FUNCTION cplusplusfunction( Steel, nType )
!DEC$ ATTRIBUTES DLLIMPORT :: cplusplusfunction
include 'STEELTYPE.H' //where my TYPE is defined...
STEELDATA Steel[reference]
integer*2 nDiam[value]
END FUNCTION cplusplusfunction
END INTERFACE

Anyone...?

[netphilou31]

The declarations in the INTERFACE statement must follow the Fortran semantics so you should write :

type (STEELDATA) Steel(reference)

and

integer(2) nDiam(value)

rather than

STEELDATA Steel[reference]
integer*2 nDiam[value]

The decalarations in your STEELTYPE.H file should also follow the fortran rules.

I hope this will be helpful

[Jugoslav_Dujic]

For the start, you're encountering a quirk in Fortran scoping rules -- INTERFACE block has its own scope, and two TYPEs are not considered the same, even if they have identical name & contents, if they're defined in different scopes, unless they have SEQUENCE attribute.

Second, I doubt that you'll get past linking stage if you don't match the exported name and calling convention. The default C++ calling convention is cdecl (!DEC$ATTRIBUTES C), so I'll assume it's used. To see the exact exported name, use dumpbin /exports cppdll.dll from command line, or open the dll in "Dependency walker" from CVF Program group. CASE MATTERS.

Third, you're using deprecated form of attributes, like [reference] -- the recommended form is !DEC$ATTRIBUTES.

The correct form of the interface should look like:

INTERFACE 
  FUNCTION cplusplusfunction( Steel, nType )
  !Alias name must match exported name. Case matters
  !DEC$ATTRIBUTES C, DLLIMPORT, ALIAS: "?cplusplusfunction_@Whatever":: cplusplusfunction
  !Either move the definition in a MODULE or insert
  !SEQUENCE in type definition. Note that SEQUENCE affects
  !padding
  USE STEELTYPE 
  !DEC$ATTRIBUTES REFERENCE:: Steel
  TYPE(STEELDATA):: Steel  
  integer*2 nDiam !Value is the default for C calling convention
  END FUNCTION cplusplusfunction
END INTERFACE

Jugoslav

[gfthomas8]

Use an interface like

INTERFACE
FUNCTION cplusplusfunction[C,ALIAS : '_cplusplusfunction] (Steel, nType )
USE STEELTYPE
TYPE(STEELDATA):: Steel[Reference]
integer*2 nDiam [Value]
END FUNCTION cplusplusfunction
END INTERFACE

and add a .def file to the project like

;DEF
Library -----
;
EXPORTS
:
:
;
IMPORTS
cplusplusfunction @1
:
:

[andersmathiesen]

Thanks everone for the help! Now it works fine!
( I didn't need any .def-file though... isn't this only for stdcall? )
/Anders

[Jugoslav_Dujic]

Specifying function names in the [EXPORTS] sections of the .def file is an alternative to !DEC$ATTRIBUTES DLLEXPORT. Similarly, [IMPORTS] section of the .def file is equivalent to !DEC$ATTRIBUTES DLLIMPORT. (However, DLLIMPORT directive is not even required for routines.)Having a .def file is a neat way to avoid polluting your code with !DEC$ATTRIBUTES, but it's optional.

Jugoslav

P.S. By the way -- Steve -- will [VALUE] form finally disappear from IVF8, or at least be accepted only under some /fpscomp switch? It seems to spread like plague ;-). I've had enough Dave Frank these days already ;-)).

[Steven_L_Intel1]

We have not considered removing the [VALUE] syntax or placing it under a switch. While I support the idea of encouraging users to use "supported" syntax, I'd have a hard time justifying such a change.

Steve

[gfthomas8]

What's so bad about VALUE or [VALUE]? Is it that it's from Dave's World? IIRC, the whole ATTRIBUTES extension directive is a handmedown from FPS and might even have been part of MS Fortran 5.1 which I never used. The [..] syntax was available in FPS and I have a preference for it because the presence of $ in Fortran annoys me even more than _ .

Ciao,
Gerry T.

[Jugoslav_Dujic]

[VALUE] actually was introduced in MSF 5.1 (or perhaps even earlier), and coutinued to exist in FPS 1.0, but discontinued & kept for backward compatibility in FPS4.0 -- !MS$ATTRIBUTES form was introduced and documented since then. I don't have FPS4 documents at hand, but I don't recall they did document [VALUE]. I find it amusing that it survived from early 90s to present times.

Personally, I find !DEC$ form less code-polluting -- one could port it (although semantics would be different). I believe in coding as close to the Standard as possible (although I admit I'm frequently lazy to follow that consistently), and IMO [VALUE] form is abominable (along with few other MS extensions, some of which luckily didn't make it into DVF/CVF, like file scope of INCLUDE statements).

As you know, F2000 with ISO_C_BINDINGS module solves most of interaction problems.

Reference to Dave was a (half)joke, of course -- he is the great promoter of [VALUE] form (and other horrors) on c.l.f, and, according to my experience, if Dave promotes something, it probably stinks ;-).

Personal preferences vary, of course, but I think that in new codes one should use standard and/or documented form where available (TYPE instead of RECORD, !DEC$ instead of [VALUE]). I note that you're using .def files instead of DLLEXPORTs -- .def files are IMO a far cleaner way, but I'm sometimes just lazy to use them :-).

Jugoslav

[Steven_L_Intel1]

We (the Intel/Compaq/DEC Fortran group) prefer to keep such things as directives, specially formatted comments that are generally ignored by compilers which do not choose to recognize them. Using invented syntax not only poses portability problems, but raises the possibility of the standard changing to define a new syntax that could be confused with the invented extension.

Yes, the ATTRIBUTES directive is wordy and "ugly". But at least, when you see it, you have a clue that it is not standard Fortran.

Steve

[gfthomas8]

The VALUE attribute in draft F2K is functionally identical, and some, to the Microsoft extension bequeated to CVF. The use of [ ] is open ever since F2K backed off on the provision of the interval data type. On Windows, different compilers have their own quirks and one readily adapts to that fact. [VALUE] is also required for inline asm.

Ciao,
Gerry T.

[Steven_L_Intel1]

The standards committee is backing the use of [] as an alternative to (//) for array constructors. CVF already supports this.

Steve

[gfthomas8]

Indeed, it's Zeliging to Matlab by the draft.

Ciao,
Gerry T.