ist es möglich eine Bibliothek in C++ für alle Plattformen (Linux, andere unix-artige, Window) zu schreiben, ohne die komplette Bibliothek mehrmals zu implementieren?

So wie ich das momentan sehe:
Shared Libraries (.so) laufen nur unter Unix etc.
DLL laufen nur unter Windows.

Muss ich also immer zweigleisig fahren? Ist es schwer, eine Shared Libary in eine DLL zu konvertieren?

Danke.

Ich habe kein Problem einen Quellcode mehrmals für verschiedene Plattformen zu kompilieren. Von mir aus gibt es eine DLL und eine SO.
Mich interessiert nur der Aufwand - ich will nicht eine Bibliothek nach einer erfolgreichen Implementierung in Linux nochmal komplett unter Windows schreiben müssen, nur weil DLL Codes anders aussehen müssen.

Systemspezifische Funktionen werden nicht verwendet.

ich will nicht eine Bibliothek nach einer erfolgreichen Implementierung in Linux nochmal komplett unter Windows schreiben müssen, nur weil DLL Codes anders aussehen müssen.

Ich weiß nicht genau, wie Linux' Shared Library's aufgebaut sein müssen, aber technisch dürfte es da wenige Unterschied geben - und um die meisten davon sollte sich der Compiler kümmern können.
(das einzige, was du eventuell neu schreiben müsstest, wäre afaik ein Äquivalent zur DllMain()-Funktion)

Mich interessiert nur der Aufwand

Das hängt stark von der Bibliothek ab. Willst du z.B. ein GUI-Toolkit schreiben, wird das sehr aufwändig.

Soll heißen: wenn du selber wiederrum nur fertig platformübergreifende Libs benutzt, wirst auch du weniger Arbeit haben. Ist doch eigentlich ganz logisch?

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

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.

Der Frager hatte ja gesagt, daß systemspezifische Funktionen nicht verwendet werden.

"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.

"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.

(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

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?

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

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?

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.

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