Boost u.a. als Abhängigkeit in öffentlicher Library nutzen?



  • Ich habe da mal eine Frage, die wohl kontrovers sein könnte.

    Ist es schön, wenn man eine recht allgemeine Library entwickelt, die wiederum eine andere Nicht-Std-Library nutzt? Im konkreten Fall geht es um Boost. Ich programmiere bekanntlich eine GUI Library (unter BSD Lizenz), und so langsam stelle ich fest, das die eine oder andere Boost Lib doch ganz hilfreich wäre. Ich selber nutze für meine Projekte natürlich Boost, aber mir geht es um die GUI Library, die für viele andere öffentlich verfügbar ist.

    Was für manche User ein Hindernis sein könnte, sind die zwei unterschiedlichen Lizenzen, die dabei wären (BSD und Boost). Oder das jemand den Boost Libs nicht traut. Und natürlich würde Boost den Build-Prozess beeinträchtigen, was mich auch bisher von Boost in der GUI Lib fern hielt.

    Bisher habe ich nur die Standard-, TR1- und Betriebssystem-Libraries genutzt. Also nur Abhängigkeiten die jede Compiler-Umgebung hat.

    Ich habe konkretes Interesse boost::any und evtl. boost::signal in der GUI Library zu nutzen und somit als Abhängigkeit (wobei es dann aber zwei Downloads geben würde, falls jemand schon Boost in seiner Compiler-Umgebung hat).

    Wie seht Ihr das? Sollte man als allgemeine Basis-Bibliothek (und als solches sehe ich die GUI Lib) andere optionale Library nutzen?



  • In Java ist das Gang und Gebe und mit Hilfe von Build-Tools wie bspw. Maven lösen sich die Abhängigkeiten auch selbst, vollautomatisch.

    In C++-Umgebungen ist dieses "komponentenorientierte" Softwareentwickeln noch nicht ganz angekommen imho. Jeder baut seine eigene String-Klasse, etc.

    Ich denke du solltest deine Entscheidung davon abhängig machen in welche Richtung du selbst C++ weiterentwickeln willst bzw. in welche Richtung sich C++ allgemein weiterentwickelt.

    Nichts hasst man doch als Entwickler mehr wenn man mal eben eine Library installiert und plötzlich 25 Abhängigkeiten mitinstalliert werden müssen und die HelloWorld-Anwendung auf 25MB gewachsen ist. Also bin ich mal dagegen wenn du nur kleine Teile von Boost nutzt. Evtl. kopierst du die Dateien und baust eine Weiche ein "Boost da? Nimm' Boost. Boost nicht da? Hier, nimm das."

    Edit: Was schreibe ich hier eigentlich...bin eigentlich derzeit zu wenig im C++-Bereich aktiv um kompetente Aussagen treffen zu können. Warte auf volkard 🙂

    MfG SideWinder



  • Ich sehe da kein Problem. Die Boost-Lizenz ist doch nur eine minimale Abwandlung der BSD- bzw. MIT-Lizenz (ist ja eher lockerer als die BSD-Lizenz). Die Boost-Lizenz ist außerdem OSI- und FSF-Approved. Das sich da jemand um die Lizenz eine Sorge macht, glaube ich nicht. Wenn jemand den Boost-Libs nicht traut, warum sollte er dann deiner Library trauen?

    Ich finde es auch überhaupt nicht ungewöhnlich, dass eine Library von einer anderen abhängt.



  • und außerdem sollte boost ohnehin schon überall installiert sein.

    Wenigstens die header-only libs. Bin da beim boost-Rest aber ehrlich gesagt sonst auch eher zurückhaltend, wegen dem nervigen Nicht-standard-Buildsystem (mit dem ich keinen Bock habe mich auseinanderzusetzen)





  • Bei Linux-Libs mache ich mir keinen Kopf, ein

    'apt-get install libboost'

    schafft noch jeder. Unter Windows können so Abhängigkeiten aber schon nerven.



  • Im professionellen Umfeld gibts auch da genug Nazi-Admins und paranoide Projektleiter, die sowas niemals nicht zulassen.



  • SideWinder schrieb:

    Warte auf volkard 🙂

    Sorry, hier will ich nicht ratgebend sein, ich würde gerne, aber kann nicht, aber auch sowas von gar nicht von.
    In meinem Umfeld wird wiederverwendung klein geschrieben. In einem Projekt sind drei queues mit identischer Funktionalität (bis auf yagni) drin, sogar eine, die mit

    #define DATA int
    #include "make_queue.h"
    #undef DATA
    

    instanziiert wird.



  • Ich finde: auf jeden Fall boost verwenden! Um zu sehen wie man es NICHT macht, schau Dir doch mal wxWidgets an:

    • keine Standardbibliothek!!!
    • keine STL!!!
    • keine Namespaces
    • keine Exceptions
    • keine Templates
    • ...

    Stattdessen:

    • eigene Stingklasse
    • eigene Container 🙄

    Und das mit so fadenscheinigen Begründungen wie: "einige Compiler unterstützen keine Exceptions/Templates". Indem man solche Libraries verwendet, kann man auch dazu beitragen, dass es so bleibt 👎
    Für mich sind das alles klare Ausschlusskriterien.

    Zurück zum Thema: Bei einer exotischen Bibliothek würde ich vielleicht abwägen, ob sich die zusätzliche Abhängigkeit lohnt. Aber boost genießt doch eine hohe Akzeptanz/Verbreitung, da finde ich es völlig OK.



  • Ethon schrieb:

    Unter Windows können so Abhängigkeiten aber schon nerven.

    Im Falle von Boost und Visual Studio ist man mit den BoostPro Installers gut beraten.

    Ansonsten ist es halt praktisch, wenn zumindest kleinere Bibliotheken mitgeliefert und wenn möglich sogar automatisch mitgelinkt werden (z.B. durch CMake).



  • Artchi schrieb:

    Ist es schön, wenn man eine recht allgemeine Library entwickelt, die wiederum eine andere Nicht-Std-Library nutzt? Im konkreten Fall geht es um Boost. [...] und so langsam stelle ich fest, das die eine oder andere Boost Lib doch ganz hilfreich wäre.
    [...]
    Bisher habe ich nur die Standard-, TR1- und Betriebssystem-Libraries genutzt. Also nur Abhängigkeiten die jede Compiler-Umgebung hat.

    Ich fürchte, vor dem genau gleichen Problem werde ich auch mal stehen. Momentan geht es zwar gerade noch knapp ohne Boost, aber die Tendenz, Dinge nachzubasteln, zeichnet sich immer mehr ab. Manchmal ist das gar nicht so schlecht, weil man etwas ohne riesigen Aufwand einfacher und intuitiver lösen kann (da ist fehlendes Boost eine gute Ausrede fürs Rad-Neu-Erfinden :)), aber bei komplexeren Dingen würde ich gerne auf vorhandenen Code zurückgreifen.

    Ich habe mir überlegt, später vielleicht einen optionalen Teil mit Boost-Abhängigkeit einzurichten, der halt nur von den Leuten mit Boost genutzt werden kann (siehe auch hier). Die zentralen Features versuche ich mit TR1 hinzukriegen. Über das Mitliefern als Headerdatei bin ich nicht besonders glücklich, zudem geht das ja auch nicht immer.



  • Nexus schrieb:

    Ethon schrieb:

    Unter Windows können so Abhängigkeiten aber schon nerven.

    Im Falle von Boost und Visual Studio ist man mit den BoostPro Installers gut beraten.

    Ansonsten ist es halt praktisch, wenn zumindest kleinere Bibliotheken mitgeliefert und wenn möglich sogar automatisch mitgelinkt werden (z.B. durch CMake).

    Auf gar keinen Fall! Damit wird es unmöglich Bibliotheken zu aktualisieren falls eine kritische Sicherheitslücke gefixt werden muss. Externe Bibliotheken sollten dynamisch gelinkt werden, und nicht mitgeliefert, so dass man Systemweit aktualisieren kann, wenn kritische Bugs gefunden werden.

    Und verwende Boost verflixt nochmal! Die Welt braucht nicht noch ein anderes Awendungsframework, schreib lieber etwas das die Chance hat boost::gui zu werden. Das wäre wenigstens sinnvoll, alles andere ist Käse 👎



  • Profi-Progger schrieb:

    Auf gar keinen Fall! Damit wird es unmöglich Bibliotheken zu aktualisieren falls eine kritische Sicherheitslücke gefixt werden muss.

    Naja, bei any oder signal sehe ich da weniger Bedarf.
    Im Gegenteil. Es ist zur Zeit gut, minimal und sícher. Wer weiß, was bei weiteren Updates noch kommen mag?



  • Ethon schrieb:

    Bei Linux-Libs mache ich mir keinen Kopf, ein

    'apt-get install libboost'

    die sind grundsätzlich zu alt oder zu neu 😉

    (was boost betrifft)



  • Artchi schrieb:

    Wie seht Ihr das? Sollte man als allgemeine Basis-Bibliothek (und als solches sehe ich die GUI Lib) andere optionale Library nutzen?

    Andere Libraries ... wenn geht bitte nicht. Ausgenommen quasi-standard Libs wie zlib, bzip2, libpng, libjpeg. Und IMO eben auch Boost.

    Wobei ich mir auch da zumindest wünsche, dass ich gleich auf die neueste Version dieser Libs updaten muss. Bei "ultrastabilen" Libs (zumindest was das Interface angeht) ala zlib ist das kein echtes Problem.

    Doof ist halt immer, wenn man auf eine neuere Version einer Library updaten soll, wo es relevante Interface-Änderungen zu der Version gibt, die man vorher schon verwendet hat.

    Was ich gar nicht abkann, sind Libs die solche Monster wie Xerces oder ICU benötigen. Wobei mir durchaus klar ist, dass es dafür oft gute Gründe gibt, nur lästig ist es für mich als Entwickler halt trotzdem.

    p.S.: wenn die fremden Libs nur intern gebraucht werden, aber nicht im Interface vorkommen finde ich DLLs eine schöne Sache. Und dann bitte die passenden Versionen in einem fertigen Source-Tree mit zum Download anbieten. Dann muss ich das Projekt nur noch bauen, und kann die DLL verwenden. Super Sache. Ob ich dann in meinem eigenen Code andere Versionen dieser intern verwendeten Libs selbe verwende ist egal, da es zu keinen "Kollisionen" kommt.



  • Profi-Progger schrieb:

    Externe Bibliotheken sollten dynamisch gelinkt werden, und nicht mitgeliefert

    Wenn die Bibliotheken nur zur Implementierung benutzt werden, ist es meiner Meinung nach schöner, wenn der Anwender sie nicht selbst linken muss. Denn da es sich um ein Implementierungsdetail handelt, kann der Bibliotheksentwickler die verwendeten Bibliotheken gegebenenfalls auswechseln oder aktualisieren, ohne dass der Benutzer was davon mitbekommt.

    Dynamisch linken kann man die Bibliotheken ja immer noch (bzw. ist das sogar das Einfachste und je nach Lizenz auch das einzig Mögliche).



  • Mir fällt gerade noch ein, dass eine GUI-Library etwas derart grundlegendes und großes in einem Projekt darstellt, dass es aus meiner Sicht doch gerechtfertigt wäre hier einige Libraries vorauszusetzen. Für größere Verbreitung sollte es für Einsteiger aber dann wirklich auch die Möglichkeit eines EXE-Install-Them-All-Add-VC-Directories-Installers geben.

    Was ich hasse sind nur Abhängigkeiten die man nicht verstehen kann. Ich habe z.B. mal eine winzige Library hinzugefügt und die hat ein 20 MB großes anderes Package verlangt. Da ich nicht verstanden habe warum, bin ich neugierig geworden und habe entdeckt, dass es eine Utility-Funktion des Utils-Package nutzt. Ich habe mich dann für eine andere winzige Library entschieden.

    MfG SideWinder



  • Danke erstmal für zahlreichen Antworten.

    Bei der Frage geht es tatsächlich um Abhängigkeiten im Interface, also kein Implementierungsdetail. Bei Implementierungsdetails würde ich nicht lange fackeln. Ich habe z.B. im Projekt auch TUT gleich mitgeliefert, davon bekommt man als Nutzer (wenn man nicht weiteres hinterfragt) nichts mit.

    Es geht also darum, das jemand auch any und signals nutzen müsste. Wobei signals nur "angekratzt" wird, in dem man connect und disconnect aufruft. Mehr nicht.

    Wie man den Boost-Pfad in die Compiler-Umgebung mit aufnimmt, würde ich in dem eh schon vorhandenen How-To zusätzlich aufnehmen. Das sollte für Einsteiger weniger ein Problem sein.

    Bei Signals wäre aber ein Binary-Build nötig. any ist dagegen (meines Wissens) Header-Only.

    Aus Euren Antworten kann ich aber die Tendenz erkennen, das eine Abhängigkeit zu Boost kein K.O. Kriterium wäre, da Boost selbst in der C++ Community recht hoch angesehen ist.

    Und wenn die Abhängigkeit kein reines Implementierungsdetail ist, soll jeder User sich um die Besorgung selber kümmern (also nicht mitliefern), damit er die Version der Abhängigkeit selbst wählen kann (soweit es die Kompatibilität erlaubt).



  • Bei Signals wäre aber ein Binary-Build nötig.

    Boost.Signals2 ist (AFAIK) Header-Only und macht erst noch gewisse Zusicherungen bezüglich Thread-Safety.



  • Zum Thema "Wie bindet man einfacher Abhängigkeiten in C++ ein", fand ich schon immer ein wichtiges Thema. Sowas wie Maven oder die ganzen Linux-Paketmanager auf C++-Compiler-Toolset-Ebene fände ich nicht unwichtig. Aber in einem separaten Thread. Sowas wäre als Projekt keine schlechte Idee. Wobei sowas wohl innerhalb eines modernen Build-Tools (SCons?) am richtigen Platz wäre.


Anmelden zum Antworten