Modulare Aufteilung einer Bibliothek



  • Ja, ich tendiere momentan auch zur Aufteilung in nur 2 Bibliotheken (Core und Rest). Die einzelnen Module abzutrennen lohnt sich wahrscheinlich nicht.

    Aber was meinst du mit "Der 2te Fall"? Würdest du zusätzlich zu den einzeln kompilierten Modulen eine Bibliothek mit allem erstellen, oder als Alternative?



  • Nexus schrieb:

    Ja, ich tendiere momentan auch zur Aufteilung in nur 2 Bibliotheken (Core und Rest). Die einzelnen Module abzutrennen lohnt sich wahrscheinlich nicht.

    Aber was meinst du mit "Der 2te Fall"? Würdest du zusätzlich zu den einzeln kompilierten Modulen eine Bibliothek mit allem erstellen, oder als Alternative?

    Naja, als alternative. Für die Leute, die lieber alles in einer .dll haben. Eventuell hat ja einer so ein Mammutprojekt dass er alle Komponenten nutzt, da macht das durchaus Sinn.
    Ich weiss ja nicht von welchen Dimensionen oder welchem Produkt wir hier reden :D.
    Ich orientiere mich immer stark an wxWidgets, da die vieles gut gelöst haben. Und ich kuck bei sowas immer gerne ab, die haben sich ja auch Gedanken gemacht :).



  • Scorcher24 schrieb:

    Naja, als alternative. Für die Leute, die lieber alles in einer .dll haben. Eventuell hat ja einer so ein Mammutprojekt dass er alle Komponenten nutzt, da macht das durchaus Sinn.

    Es wären in diesem Fall entweder 1 oder 2 Bibliotheken. Falls ich mich für zwei Teile (Core und Rest) entscheide, werde ich keinen dritten mit allem zusammen anbieten, hätte auch keinen grossen Vorteil.

    Scorcher24 schrieb:

    Ich orientiere mich immer stark an wxWidgets, da die vieles gut gelöst haben. Und ich kuck bei sowas immer gerne ab, die haben sich ja auch Gedanken gemacht :).

    Naja, je nachdem hört man da aber auch anderes, vor allem im Bezug auf modernes C++. Wenn ich sowas lese, stelle ich die Vorbildfunktion schon etwas in Frage 😉



  • Der Guide ist uralt. Davon abgesehen ist das Ziel von wxWidgets XPlatform und eine große Compilerunterstützung. Und da müssen Kompromisse gemacht werden. QT hat nen Präprozessor, wxWidgets bedient sich halt einiger streitbarer Richtlinien. Einen Tod muss jeder sterben am Ende.



  • Ich frage mich wirklich, ob es es wert ist, auf moderne (oder besser: nicht uralte und mehrfach überholte) C++-Sprachmittel und -Techniken zu verzichten, nur damit der Code auch auf Windows 3.1 läuft.
    Das Design von wxWidgets war für mich immer das Totschlagargument und wenn ich sowas lese wie "benutzt nicht die STL, benutzt wxString!", fühle ich mich sehr bestätigt.



  • ipsec schrieb:

    Ich frage mich wirklich, ob es es wert ist, auf moderne (oder besser: nicht uralte und mehrfach überholte) C++-Sprachmittel und -Techniken zu verzichten, nur damit der Code auch auf Windows 3.1 läuft.
    Das Design von wxWidgets war für mich immer das Totschlagargument und wenn ich sowas lese wie "benutzt nicht die STL, benutzt wxString!", fühle ich mich sehr bestätigt.

    Das ist mittlerweile doch gar nicht mehr aktuell.. die aktuelle Version nutzt die STL durchaus.



  • Gut ich geben zu, ich bin nicht auf dem Laufenden. Mein Interesse für wxWidgets ist einst erloschen, als ich erfahren habe, dass man "generische" Container mit Makros definiert und wie sehr angepriesen wurde, welche Vorteile die doch gegenüber Templates hätten.
    Ist das immer noch so?



  • Es gibt als Beispiel wxVector, welches die Funktionalität eines STL-Vectors implementiert. Definiert man STL als erwünscht, dann ist das nur ein typedef. Auf Systemen auf denen es den STL-Vector nicht gibt, hat man dann den eigenen als Fallback.
    Da hat sich also einiges getan.
    http://docs.wxwidgets.org/trunk/classwx_vector_3_01_t_01_4.html



  • Nexus schrieb:

    Wie würdet ihr vorgehen? Gibt es weitere Möglichkeiten?

    Ich würde die 10 Teile lassen, und für Windows Auto-Link über #pragma comment(lib) implementieren. Dann stört das nämlich kaum noch.
    Den Linuxern bringt das natürlich nixe, aber die sollen endlich mal zusehen dass sie auch ein Auto-Link pragma implementiert bekommen.

    Würdest du dem Benutzer also eher nicht ermöglichen, sich die Bibliothek zusammenzubasteln? D.h. er könnte die benötigten Teile auswählen und zu einer einzelnen statischen/dynamischen Bibliothek kompilieren?

    Wenn er das möchte kann er ja immer noch statisch linken. Der Linker eliminiert dann eh alle Importe die nirgends gebraucht werden, d.h. man braucht dann auch XYZ.dll nicht, wenn man keine Funktionen deiner .LIB aufruft die (direkt oder indirekt) XYZ.dll benötigen.

    EDIT: OK, zum Bauen braucht man natürlich trotzdem die Header-Files der XYZ.dll. Das könnte lästig sein... Hm... /EDIT



  • hustbaer schrieb:

    Den Linuxern bringt das natürlich nixe, aber die sollen endlich mal zusehen dass sie auch ein Auto-Link pragma implementiert bekommen.

    😃

    Mal schauen... Auto-Link wäre manchmal schon praktisch. Überhaupt gilt das für einige compilerspezifische Dinge. Aber 10 einzelne Bibliotheken sind mir generell nicht ganz geheuer. Da wohl meistens alle aufs Mal benötigt werden, kommt mir der Nutzen im Vergleich zur Komplexität zu klein vor. Zudem besteht die Möglichkeit, dass in Zukunft weitere Module dazukommen.

    Beim Bauen müsste man eventuell eine mühsame Fallunterscheidung mit Makros durchführen, um bedingt zu kompilieren. Was spricht denn eigentlich konkret gegen eine Bibliothek, bei deren Erstellung der Benutzer die zu kompilierenden Teile auswählen kann (mit CMake)? Gibt es Nachteile ausser der Binär-Inkompatibilität und der möglichen Verwirrung durch verschiedene Kombinationen?



  • Nexus schrieb:

    Was spricht denn eigentlich konkret gegen eine Bibliothek, bei deren Erstellung der Benutzer die zu kompilierenden Teile auswählen kann (mit CMake)? Gibt es Nachteile ausser der Binär-Inkompatibilität und der möglichen Verwirrung durch verschiedene Kombinationen?

    Ja, der Aufwand die Make-Files/Skripte zu schreiben & zu warten.



  • hustbaer schrieb:

    Ja, der Aufwand die Make-Files/Skripte zu schreiben & zu warten.

    Meinst du das aus Sicht der Anwender meiner Bibliothek? Also falls sie bestimmte Module linken wollen?

    Denn für mich sollte das mit CMake keine allzu grosse Sache sein...



  • Nene, ich meine schon aus Sicht des/der Library-Entwickler(s).

    Wobei ich persönlich auch als Anwender einer Library keine CMake Projekte mag, ich hab's lieber wenn da ein schönes .sln File dabei liegt (oder 2 oder 3, für verschiedene Studio-Versionen).



  • hustbaer schrieb:

    Wobei ich persönlich auch als Anwender einer Library keine CMake Projekte mag, ich hab's lieber wenn da ein schönes .sln File dabei liegt (oder 2 oder 3, für verschiedene Studio-Versionen).

    Ja, ich werde wahrscheinlich versuchen, bei grösseren Versionen Projekte/Makefiles für die wichtigsten IDEs/Compiler mitzuliefern. Stimmt, hier wäre dann so ein Zusammenbasteln nicht mehr möglich.

    Ansonsten haben Visual Studio 2010-Benutzer sowieso Glück, da ich die IDE selbst verwende 🙂



  • Zu meinem Verständnis nachgefragt: "Da ist eine oder es sind mehrere Bibliotheken als LIB oder DLL verfügbar, die der Anwender in seine Projekte einbinden kann". Soweit richtig verstanden? Wo nun gibt es da Probleme mit der Portabiltität auf unterschiedliche Zielsysteme, Compiler und Co.?



  • berniebutt schrieb:

    Zu meinem Verständnis nachgefragt: "Da ist eine oder es sind mehrere Bibliotheken als LIB oder DLL verfügbar, die der Anwender in seine Projekte einbinden kann". Soweit richtig verstanden?

    Ja. Ob es eine oder mehrere sein sollen, ist die Frage dieses Threads.

    berniebutt schrieb:

    Wo nun gibt es da Probleme mit der Portabiltität auf unterschiedliche Zielsysteme, Compiler und Co.?

    Nirgends, um Portabilität geht es nicht. "lib" und "dll" heisst nicht, dass man nur für Windows kompilieren kann (daher auch CMake). 🙂


Anmelden zum Antworten