Tweet
Hi Leute
Ich mache mir zur Zeit Gedanken wie ich die Interfaces am cleversten nutzen kann und was wohl der beste Kompromiss zwischen Design, Portabilität und Flexibilität ist. Ich möchte nicht auf die Windows COM Schiene mit IDispatch usw. Möchte aber das es unter umständen sehr leicht ist meine Interfaces auch aus anderen Sprachen, z.B. BCB, oder aus DLL's heraus zu nutzen. z.B.
<pre>
type
ISmallPrimes = interface
['{126BE100-061D-4067-9E0A-E2A490AF5CEA}']
function GetPrime(Index: cardinal): Cardinal; stdcall;
property Prime[Index: Cardinal]: Cardinal read GetPrime; default;
end; <br>
function Primes: ISmallPrimes; stdcall; <br>
</pre>
D.h. im Falle der Nutzung aus DLL's oder anderen Sprachen muß diese die Interface-Deklaration importieren und die jeweilige function Primes.
Nun tauchen aber wichtige Fragen auf
<li>welche Calling-Konvention sollte benutzt werden ?
<li>welche Datentypen (Integer, Cardinal usw.) sollte preferiert werden ?
<li>welche Datentypen sollten NICHT verwendet werden ?
<li>welchen Datentyp für Strings ? vollständig vermeiden ?
<li>wie mit komplexen Strukturen arbeiten ?
<li>wie allozierte Speicherparameter übergeben, nutzen ?
<li>wie werden Variants vermieden ?
<li>in wie weit erreicht man die höchste, spätere, Kompatibilität ohne den Overhead von COM,ActiveX und ohne viel vom PASCAL Objectdesign abzuweichen ?
<li>wichtig ist die Kylix Kompatibilität !<br>
Grundsätzlich bieten die Interfaces mit dem Referencecounting einen sehr komfortablen Weg der Speicher/Lifetimeverwaltung, diesen Vorzug will ich nutzen.<br>
Generell würden mir Allozierungs-Funktionen wie oben gezeigt völlig ausreichen. Auf jeden Fall müsste man dann die Verwendung von Delphi Objecten verweiden, ich meine als User-Interface, also nur intern in der mplementierung.<br>
Andreas, Du als Experte, kannst mich bestimmt aufklären.<br>
Gruß Hagen
Ich mache mir zur Zeit Gedanken wie ich die Interfaces am cleversten nutzen kann und was wohl der beste Kompromiss zwischen Design, Portabilität und Flexibilität ist. Ich möchte nicht auf die Windows COM Schiene mit IDispatch usw. Möchte aber das es unter umständen sehr leicht ist meine Interfaces auch aus anderen Sprachen, z.B. BCB, oder aus DLL's heraus zu nutzen. z.B.
<pre>
type
ISmallPrimes = interface
['{126BE100-061D-4067-9E0A-E2A490AF5CEA}']
function GetPrime(Index: cardinal): Cardinal; stdcall;
property Prime[Index: Cardinal]: Cardinal read GetPrime; default;
end; <br>
function Primes: ISmallPrimes; stdcall; <br>
</pre>
D.h. im Falle der Nutzung aus DLL's oder anderen Sprachen muß diese die Interface-Deklaration importieren und die jeweilige function Primes.
Nun tauchen aber wichtige Fragen auf
<li>welche Calling-Konvention sollte benutzt werden ?
<li>welche Datentypen (Integer, Cardinal usw.) sollte preferiert werden ?
<li>welche Datentypen sollten NICHT verwendet werden ?
<li>welchen Datentyp für Strings ? vollständig vermeiden ?
<li>wie mit komplexen Strukturen arbeiten ?
<li>wie allozierte Speicherparameter übergeben, nutzen ?
<li>wie werden Variants vermieden ?
<li>in wie weit erreicht man die höchste, spätere, Kompatibilität ohne den Overhead von COM,ActiveX und ohne viel vom PASCAL Objectdesign abzuweichen ?
<li>wichtig ist die Kylix Kompatibilität !<br>
Grundsätzlich bieten die Interfaces mit dem Referencecounting einen sehr komfortablen Weg der Speicher/Lifetimeverwaltung, diesen Vorzug will ich nutzen.<br>
Generell würden mir Allozierungs-Funktionen wie oben gezeigt völlig ausreichen. Auf jeden Fall müsste man dann die Verwendung von Delphi Objecten verweiden, ich meine als User-Interface, also nur intern in der mplementierung.<br>
Andreas, Du als Experte, kannst mich bestimmt aufklären.<br>
Gruß Hagen
Comment