Plattformunabhängige C++ Bibliotheken
-
Dann wird der Aufwand eher minimal sein. Wenn du z.B. hauptsächlich Std-Lib-Komponenten benutzt, ist der Aufwand praktisch null. (so sollte es zumindest sein ;)) Wenn es um Netzwerk-Sachen geht, kannst du z.B. eine platformneutrale Netzwerk-Lib wie Boost.asio benutzen, und dann müsste auch hier der Aufwand praktisch null sein.
Soll heißen: wenn du selber wiederrum nur fertig platformübergreifende Libs benutzt, wirst auch du weniger Arbeit haben. Ist doch eigentlich ganz logisch?
-
Es gibt einen ANSI-C++-Standard. Wenn Du Dich an den hälst, ist der Code portabel. Da ist es unerheblich, ob der Code zu einer Applikation, einer shared-library oder eine DLL gelinkt wird.
In der Praxis gibt es immer wieder mal Probleme, wenn man unterschiedliche Compiler verwendet. Diese lassen sich aber in der Regel durch Studium des ANSI-Standards genau einem Schuldigen zuweisen.
Meine Erfahrung ist, daß die meisten Probleme daher kommen, daß das eigene Programm sich nicht exakt an den Standard hält. Tut man dies, gibt es wenig Probleme.
Tntnet
-
tntnet schrieb:
Es gibt einen ANSI-C++-Standard. Wenn Du Dich an den hälst, ist der Code portabel. Da ist es unerheblich, ob der Code zu einer Applikation, einer shared-library oder eine DLL gelinkt wird.
In der Praxis gibt es immer wieder mal Probleme, wenn man unterschiedliche Compiler verwendet. Diese lassen sich aber in der Regel durch Studium des ANSI-Standards genau einem Schuldigen zuweisen.
Meine Erfahrung ist, daß die meisten Probleme daher kommen, daß das eigene Programm sich nicht exakt an den Standard hält. Tut man dies, gibt es wenig Probleme.
Tntnet
Na ja, die eigentlichen Probleme treten auf, wenn auf Libraries von 3ten angewiesen ist. Dass Libraries Multiplattformfaehig sind ist laengst nicht selbstverstaendlich. Viel wichtiger als 100% Standardkonform zu sein ists IMO, bei der Librarywahl vorsichtig zu sein.
-
Eigentliche Probleme gibt es viele. Ich halte es für unnötig zu erwähnen, daß plattformspezifische Bibliotheken nicht plattformübergreifend sind.
.Der Frager hatte ja gesagt, daß systemspezifische Funktionen nicht verwendet werden.
-
Danke für die Hilfe - das hört sich doch ganz gut an.
"eine platformneutrale Netzwerk-Lib wie Boost.asio"
Ich habe immer gedacht die Standardbibliotheken liefern mir da entsprechende Funktionialitäten - oder war das in C?
Egal, ich werd' mich umsehen.
-
Frager schrieb:
"eine platformneutrale Netzwerk-Lib wie Boost.asio"
Ich habe immer gedacht die Standardbibliotheken liefern mir da entsprechende Funktionialitäten - oder war das in C?Nein, Netzwerkunterstützung gehört (leider?) nicht zum ANSI-Standard.
-
CStoll schrieb:
(das einzige, was du eventuell neu schreiben müsstest, wäre afaik ein Äquivalent zur DllMain()-Funktion)
Diese Perversion bleibt Nutzern von Shared Objects zum Glück erspart.
Bzw. (Linux):
Früher gab es _init und _fini Funktionen, diese sind heute deprecated und es gibt constructor und destructor als Funktionsatttribut. Das wird dann glaub ich auch für die globale-Objekte-Konstruktor-Funktion benutzt.
Bzw., falls die Frage auftaucht "Warum Perversion?"... Mindestens folgende Dinge darf man in DllMain nicht machen:
- DLLs laden
- Threads starten
-
Ok danke nochmals, eine Frage hätte ich dann noch. Sie mag ein wenig ungebildet klingen, aber ich habe mich mit C++ Bibliotheken (gerade unter Linux) bisher nur wenig befasst:
Welche Einschränkungen bezüglich objektorientierter Programmierung gibt es? Kann ich zum Beispiel in einer Bibliothek (sei es Linux oder Windows) eine Klasse definieren, die später eine andere Klasse außerhalb der Bibliothek beerbt?
-
Du kannst in einer Bibliothek Basisklassen definieren und in deinem Hauptprogramm ableiten. Andersrum geht es nicht, da die Bibliothek nicht gegen dein Hauptprogramm linken kann und daher die Funktionen des Hauptprogramms nicht zur verfügung stehen.
Ich habe in meinem Tntnet eine shared library libtntnet, welches alles enthält, was sowohl das Hauptprogramm tntnet als auch die Komponenten, die als shared library zur Verfügung gestellt werden, benötigen.
Übrigens sind diese DllMain- und sonstigen Funktionen unnötig. Man kann statische Objektinstanzen anlegen deren Konstruktoren zur Ladezeit aufgerufen werden.
Tntnet
-
Danke für deine Antwort - ich wollte natürlich aus dem Hauptprogramm heraus eine Klasse ableiten. Dass es anders herum nicht geht, ist klar.
Dein TNTNET Projekt klingt sehr interessant. Wie kann ich mir das eigentlich vorstellen? Ist das ein komplett eigener Webserver oder eher eine Art Application-Server der z.B. mit dem Apache via CGI verknüpft werden kann?
-
tntnet schrieb:
Andersrum geht es nicht, da die Bibliothek nicht gegen dein Hauptprogramm linken kann und daher die Funktionen des Hauptprogramms nicht zur verfügung stehen.
Doch. Ist aber nicht unbedingt empfehlenswert.
-
Frager schrieb:
Danke für deine Antwort - ich wollte natürlich aus dem Hauptprogramm heraus eine Klasse ableiten. Dass es anders herum nicht geht, ist klar.
Dein TNTNET Projekt klingt sehr interessant. Wie kann ich mir das eigentlich vorstellen? Ist das ein komplett eigener Webserver oder eher eine Art Application-Server der z.B. mit dem Apache via CGI verknüpft werden kann?
Es ist ein eigenständiger Webserver. Genauere Infos gibt es auf der Homepage oder in der Dokumentation oder im IRC unter Freenode #tntnet.
Gruß
Tntnet