Interfaces COM, CORBA oder gar nicht ?

[magnetron]

Hallo,
ich plane ein grösseres Projekt zu erweitern und ein wenig zukunftssicherer zu machen.
Es handelt sich um mehrere libraries, in denen Geräte angesprochen werden und die irgendwelche Daten liefern.
Das ganze ist multithreaded, aber vermutlich für die Frage egal.

Ich hätte gerne ein Objekt (ohne LCL-GUI Komponenten) in einer library (so, DLL), also zum Beispiel ein Multimeter.
Dieses würde ich gerne instanzieren und als Klasse benutzen.

Mein Kenntnisstand sagt, Interfaces seien die einzige Möglichkeit eine Klasse in eine library zu packen ?
Ich habe dafür bislang Interfaces (COM) verwendet und soweit begriffen. Dennoch um eine Sackgasse zu
vermeiden die konkreten Fragen:
- Überhaupt interfaces ?
Ich habe das Gefühl, Interfaces werden selten verwendet ?
Besser API prozedural exportieren und danach wieder eine Klasse basteln ?
- Wenn ja, COM oder CORBA ?
Ich habe das mit COM bisher hinbekommen aber das refcounting raubt mir den letzten Nerv.
CORBA aber scheinen noch weniger Programmierer zu verwenden als COM ?
Ich finde Interfaces ohne Refcounting jedoch mit Properties sehr sympathisch aber
wird das in einigen Jahren auch noch unterstützt oder ist das eine Sackgasse ?

Wie gesagt es sind einige libraries, die alle zusammenarbeiten sollen und ich habe bislang keine andere Idee
als Interfaces um Klassen in libraries zu packen.

Vielen Dank schon mal, viele Grüße,
Stefan

[af0815]

Noch eine Frage dazu - welche Plattformen soll das Projekt unterstützen ? Aus der Beschreibung erkenne ich nur Windows, ist das richtig ?

[magnetron]

Hallo,

gute Frage.
Persönlich bin ich linux only unterwegs, mein Lehrer - sagen wir Mentor - jedoch windows only.
Ich schätze sehr die Plattformunabhängigkeit von Lazarus wo selbst grössere Projekte mit
keinen bis wenig $ifdefs sofort laufen.

Mir würde linux only ausreichen. Es wäre aber schön, wenn es auf windows laufen würde und es
wäre schön, wenn die Chance besteht, dass daran interessierte das ganze nutzen und ggf. erweitern können.

Grüße, Stefan

edit:
zur Präzisierung:
ich muß keine Windows libraries nutzen. Audio sampling mach ich nativ oder portaudio, geht beides.
Also ich bin nicht auf COM oder windows Spezifika angewiesen.
Es geht nur um die sinnvollste Planung des Projektes (wessen Vorfahre mit Iinterfaces ala COM realisiert ist).

[mse]

- Wenn ja, COM oder CORBA ?
Ich habe das mit COM bisher hinbekommen aber das refcounting raubt mir den letzten Nerv.
CORBA aber scheinen noch weniger Programmierer zu verwenden als COM ?
Ich finde Interfaces ohne Refcounting jedoch mit Properties sehr sympathisch aber
wird das in einigen Jahren auch noch unterstützt oder ist das eine Sackgasse ?

MSEgui nutzt CORBA-Interfaces extensiv, die Methode hat sich bewährt und ist sicher keine Sackgasse.
Da MSEgui früher Delphi kompatibel war und Delphi lediglich referenz-gezählte COM-Interface hatte, kann ich deine Erlebnisse mit COM gut nachvollziehen, die haben mir auch den letzten Nerv geraubt.
Bei Free Pascal kommt hinzu, dass der Zeitpunkt wann die Referenz 0 erreicht und das Objekt abgeräumt wird als "Implementations-Detail" betrachtet wird und man sich nicht darauf verlassen kann. Bei Delphi ist das etwas besser.
Das mit Klassen in DLL/SO's gepackt würde ich mir nochmals überlegen. Free Pascal kennt keine "Packages" wie Delphi. Jede einzelne DLL hat ihre eigene Speicher-Verwaltung und eigene Kopie der Basisklassen. Schon nur die modulübergreifende Verwendung von Strings ist nicht einfach.
Was versprichst du dir von der Verwendung von DLL/SO's anstatt von units?
Falls du noch nie von MSEide+MSEgui gehört hast, das Projekt mit den vielen CORBA-Interfaces ist hier:
http://sourceforge.net/projects/mseide-msegui/

[mschnell]

Mein Kenntnisstand sagt, Interfaces seien die einzige Möglichkeit eine Klasse in eine library zu packen ?

Wieso ? Eigentlich sind (meiner Meinung nach) solche Interfaces bezüglich Libraries nur ein praktisches add-on, weil ein standardisiertes Format existiert durch das beim Design der aufrufenden Application die IDE automatisch ein Interface "importieren" und eine Unit mit Zugriffs-Funktionen/Klassen konstruieren kann.

Man kann mit fpc keine C++ Klassen aufrufen und umgekehrt (egal ob per dynamischem (DLL/so) oder durch statisches Linken).

Wenn beides mit fpc generiert ist, kann auch in einer dll/so eine Klasse verwendet werden.

Ein Problem gibt es allerdings bei der Heap-Verwaltung. Soweit ich weiß, hat eine dll/so bei fpc eine eigene Heap-Verwaltung. Man darf deshalb nichts z.b. im Executable allokieren und in der Library freigeben, weil die entsprechenden Funktionen unterschiedliche Heap-Verwaltungen aufrufen. Das Problem tritt am deutlichsten bei Strings zutage, die ja "reference-counted" automatisch angelegt und freigegeben werden und deshalb nicht unbedacht an eine Library -Funktion übergeben werden dürfen. Beim "Create" und "Destroy" einer Klasse wird ebenfalls automatisch Heap allokiert und deallokiert. Soweit ich weiß gibt es eine Möglichkeit, die Heapverwaltungen zu vereinheitlichen. (Macht Delphi z.B. bei "Rutime-Libraries". Soweit ich weiß stehen Runtime-Libraries beim FPC-Team auf der ToDo-Liste).

Ein weiteres Problem betrifft GUI-Funktionen. Soweit ich weiß hat - wenn man es einbindet - die dynamische Library ein eigenes "Application" Objekt und somit eine komplett eigene GUI. Da aber kein Thread dafür angelegt wird, "läuft" diese überhaupt nicht und es wird kein Main-Window angelegt. Aber die GUI Objekte in der Library sind auch keine "Kinder" des Main-Windows der gestarteten Application. (Vermutlich ist auch das bei Delphi "Runtime_Libraries" vereinheitlicht.)

-Michael

[Patito]

Noch eine Frage dazu wäre, ob man den Code in anderen Programmiersprachen verwenden will.

Bleibt man innerhalb von Pascal, kann man die Klassen/Units auch ohne Umweg direkt verwenden.
Meine Libraries stellen meistens per Fassade-Pattern ein Interface bereit, über das man auf die
Funktionen der Library zugreifen kann. Referenzzählung ist dabei immer nur ein unnötiges Hindernis.

Dieselben Klassen in verschiedenen Programmiersprachen verwenden zu wollen ist problematisch.
COM/ActiveX wurde genau dafür gemacht, ist aber in der Praxis ein ziemlicher Murks (und Windows-spezifisch).
Wenn eine sprachübergreifende API etwas taugt, ist sie normalerweise rein prozedural und C-kompatibel.

Um dann wieder komfortabel mit Klassen arbeiten zu können, benötigt man für jeder Sprache noch einen Wrapper,
der die ganzen prozeduralen Objekt-Handles wieder in Objekte übersetzt.

procedure Test(Handle: TMyHandle; a, b, c: Integer)
->
procedure TMyObject.Test(a, b, c: Integer);

[mschnell]

procedure Test(Handle: TMyHandle; a, b, c: Integer)
->
procedure TMyObject.Test(a, b, c: Integer);

Willst Du dann in ANSI-C die Objekt-Struktur von fpc aufdröseln ?

-Michael

[Patito]

... Übersetzung C-API -> Object-Pascal

Willst Du dann in ANSI-C die Objekt-Struktur von fpc aufdröseln ?

???

Nein. Object-Pascal -> C-API ist die entgegengesetzte Richtung....

[magnetron]

Vielen Dank für die hilfreichen und fundierten Kommentare.
Meine Grundidee war, dass ich nur kleinere Teile programmieren muss und diese
dass in Form einer DLL wiederverwenden kann.
Eure Kommentare haben mir weitergeholfen und ich denke noch etwas drüber nach.

MSEgui nutzt CORBA-Interfaces extensiv, die Methode hat sich bewährt und ist sicher keine Sackgasse.

Das freut mich und klingt sympathisch. Ob ich Interfaces brauche wage ich nun aber zu bezweifeln.

Was versprichst du dir von der Verwendung von DLL/SO's anstatt von units?

Ich dachte mein Programm wird vielleicht in einfachere Teile aufgeteilt und ist besser les- und pflegbar.
Bei längerem Nachdenken über Deine wirklich gute Frage müsste das aber mit units genauso zu erreichen sein ohne den Verwaltungsoverhead für die dlls und evtl. ohne andere Nachteile.

Wenn beides mit fpc generiert ist, kann auch in einer dll/so eine Klasse verwendet werden.
Ein Problem gibt es allerdings bei der Heap-Verwaltung....
... Ein weiteres Problem betrifft GUI-Funktionen..

Stimmt vermutlich, daher habe ich auf GUI in dll verzichtet. Bezüglich Datenübergabe
fragt der Aufrufer wieviel er allozieren muss und holt dann die Daten ab (als Kopie).
Funktioniert aber macht wieder overhead.
Wenn ich (nur) units nehme, wird gerade der Datentransfer innerhalb des Programmes einfacher und überschaubarer vermute ich.

Bleibt man innerhalb von Pascal, kann man die Klassen/Units auch ohne Umweg direkt verwenden.
Meine Libraries stellen meistens per Fassade-Pattern ein Interface bereit, ...
...Wenn eine sprachübergreifende API etwas taugt, ist sie normalerweise rein prozedural und C-kompatibel.

Ich bleibe in fpc. Externe API erstmal nicht nötig.
Mit units könnte ich dann (doch wieder) dynamische arrays und sonstige Datentypen nach belieben verwenden.

Im Moment komme ich also zum Schluss, dass ich die Einzelteile sauber in units unterbringe
(die auch separat prüfbar/pflegbar sind) und aus diesen (dann vielen) units ein Programm baue für eben seinen Zweck.

Nochmal danke für die konstruktive Hilfe, tolles Forum,
Grüße, Stefan

[mschnell]

???

Nein. Object-Pascal -> C-API ist die entgegengesetzte Richtung....

Die Richtung ist egal. "Dröseln" geht nur in ANSI C, egal ob Du die Information von fpc bekommst und analysiert oder so vorbereitesn willst, dass fpc sie versteht..

Jedenfalls nicht ganz trivial.

-Michael

[marcov]

Das mit Klassen in DLL/SO's gepackt würde ich mir nochmals überlegen. Free Pascal kennt keine "Packages" wie Delphi. Jede einzelne DLL hat ihre eigene Speicher-Verwaltung und eigene Kopie der Basisklassen. Schon nur die modulübergreifende Verwendung von Strings ist nicht einfach.

Und wenn mehrere Kompilers oder -versionen im Spiel kommen wird es noch schlimmer.

Man wird dann einfach weg zurück geworfen auf ganz separierter manuelle Speicher Allokation (1) und reine Prozedurale . (2)

(1) das heißt das der Programmteil (exe,dll) der etwas allokiert es auch muss freigeben.
(2) wird auch oft falsch ein C Api genannt. Ist strikt genommen aber der niedrigsten gemeinsame Teiler der prozedurale Fähigkeiten der betroffen Sprachen. Wenn ein davon ein C ist, werden gewisse Dingen angenommen, ist aber sehr unexakt.

Das einzige das besser ist (also auf Object Ebene, und automatische (wide-)strings) ist COM. Also auf Windows. Das Funktioniert, aber dann muss man auch wirklich fuer gehen, also die Regeln folgen, und nicht mit ein Paar der COM Techniken (wie COM interfaces) selbst etwas basteln.

Es gibt einige versuche auf Linux (wie XPCOM für Mozilla) sind aber nicht universell und oft nicht robust Versionsweise. (also nur heutiger KDE/Mozilla usw Version)

Interfaces (Corba oder nicht) lösen das Hauptproblem, Speicherverwaltung nicht.