C DLL Funktion einbinden - eary binding vs. late binding

[PeterS]

Hallo,

ich verstehe noch nicht genau, warum der Compiler einen Unterschied macht
wenn ich eine Funktion aus einer DLL "early" oder "late" einbinde.

Folgendes Beispiel:

Code: Alles auswählen

int Pa_GetVersion( void );

Für early binding ist das hier deklariert

Code: Alles auswählen

function Pa_GetVersion(): cInt; cdecl; external LibName;

Damit funktioniert in Lazarus das hier (=> early binding), mit 32 bit Lazarus / 32 bit Compiler.

Code: Alles auswählen

  Result:= 'PA version int:   ' +IntToStr( Pa_GetVersion);

Für late binding ist das hier deklariert

Code: Alles auswählen

var Pa_GetVersion: function():cInt ; cdecl;
..

function Pa_Load( const libfilename:string):boolean;
..
          Pointer( Pa_GetVersion):= DynLibs.GetProcedureAddress( PA_Handle, pAnsiChar( 'Pa_GetVersion'));

Das heißt für mich, das Programm kennt (nach Aufruf von Pa_Load) die Adresse der Funktion in der externen C DLL.
Und auch den Ergebnis-Typ der Funktion, denn der ist ja deklariert als cInt. Oder ?

Damit funktioniert das hier aber nicht ..

Code: Alles auswählen

  Result:= 'PA version int:   ' +IntToStr( Pa_GetVersion);

und der Compiler meckert:

Error: Incompatible type for arg no. 1: Got "<procedure variable type of function:LongInt;CDecl>", expected "QWord"
sysstr.inc(861,10) Hint: Found declaration: IntToStr(QWord):AnsiString;
sysstr.inc(856,10) Hint: Found declaration: IntToStr(Int64):AnsiString;
sysstr.inc(850,10) Hint: Found declaration: IntToStr(LongInt):AnsiString;


Der Compiler ruft also IntToStr(QWord) auf statt IntToStr(LongInt) - und das geht natürlich nicht.
Eigentlich müßte der Compiler doch wissen daß function result von Pa_GetVersion = Typ cInt ist ??
Und daher IntToStr(LongInt) anwenden ?

[PeterS]

Beim "Fehler" beschreiben habe ich es jetzt endlich selber herausgefunden.

Code: Alles auswählen

  Result:= 'PA version int:   ' +IntToStr( Pa_GetVersion);

ist nicht dasselbe wie

Code: Alles auswählen

  Result:= 'PA version int:   ' +IntToStr( Pa_GetVersion() );

[Mathias]

Hast du auch Herausgefunden, wieso es verschiedene Werte gibt ?
Oder hast du einfach nur den Fehler gefunden ?

[PeterS]

Hast du auch Herausgefunden, wieso es verschiedene Werte gibt ?
Oder hast du einfach nur den Fehler gefunden ?

Ich gehe davon aus daß das Programm mit "late binding" und dem folgenden Code ..

Code: Alles auswählen

  Result:= 'PA version int:   ' +IntToStr( Pa_GetVersion);

die Adresse der Funktion "Pa_GetVersion" anzeigt, aber nicht die Funktion aufruft.
Also die Adresse, die mit DynLibs.GetProcedureAddress() an die VAR Pa_GetVersion zugewiesen wurde
=>

Code: Alles auswählen

var Pa_GetVersion: function():cInt ; cdecl; 

[Zvoni]

Ein weiterer Punkt für Überlegungen "Early vs. Late Binding"
1) Bei Early Binding bist du vollständig davon abhängig, dass der Pfad zu deiner Lib dem System bekannt ist
2) Bei Late Binding kannst du im Prinzip die Lib ablegen, wo du willst. Du musst nur den Pfad an LoadLibrary mitgeben.

1) Ist sinnvoll, wenn du auf System-Libs zugreifst, die definitiv am korrekten Platz existieren
2) Ist sinnvoll, wenn du auf "optionale" Libs zugreifen willst. (Libs, welche unter Umständen woanderst hin installiert wurden).
Hier kann dann auch ganz einfach geprüft werden, ob die Lib überhaupt auf dem System vorhanden ist

[PascalDragon]

Beim "Fehler" beschreiben habe ich es jetzt endlich selber herausgefunden.

Code: Alles auswählen

  Result:= 'PA version int:   ' +IntToStr( Pa_GetVersion);

ist nicht dasselbe wie

Code: Alles auswählen

  Result:= 'PA version int:   ' +IntToStr( Pa_GetVersion() );

In den Nicht-Delphi Modi müssen parameterlose Routinenzeiger mit leeren Klammern aufgerufen werden, um zwischen einer Verwendung als Variable und einem Aufruf zu unterscheiden.

[Mathias]

In den Nicht-Delphi Modi müssen parameterlose Routinenzeiger mit leeren Klammern aufgerufen werden, um zwischen einer Verwendung als Variable und einem Aufruf zu unterscheiden.

Dann interpretiert Delphi die immer als Funktions-Ergebnis, oder ist die umgekehrt ?
Bei Delphi muss man bei den Callproc auch kein @ machen.

[PascalDragon]

In den Nicht-Delphi Modi müssen parameterlose Routinenzeiger mit leeren Klammern aufgerufen werden, um zwischen einer Verwendung als Variable und einem Aufruf zu unterscheiden.

Dann interpretiert Delphi die immer als Funktions-Ergebnis, oder ist die umgekehrt ?
Bei Delphi muss man bei den Callproc auch kein @ machen.

Es kommt bei Delphi ein bisschen auf den Kontext an und es ist nicht wirklich dokumentiert. Deswegen sind die meisten Methodenzeiger in Delphi wohl procedure, um eben das Problem zu umgehen...
In mode Delphi versucht FPC sich da an die Regeln von Delphi zu halten, aber wir hatten da schon Bugfixes in der Vergangenheit, weil sich Delphi dann doch anders verhält als erwartet...