Boost u.a. als Abhängigkeit in öffentlicher Library nutzen?
-
theta schrieb:
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.
Echt? Wusste das es Signals2 gibt, aber nicht das es Header-Only ist.
Mich persönlich stören Binary-Libs nicht, ich kann sie mit bjam bauen und gelinkt werden sie mit MSVC eh automatisch. Aber es gibt ja Menschen, die mit Binary-Libs auf Kriegsfuß stehen... würde ja schon mal eine Hürde weniger da sein!
-
Ethon schrieb:
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.
Könnte man natürlich auch für den MSVC bzw. das Windows SDK aufziehen. Müsste sich aber eine Community aufbauen, die dann die Libs auch pflegt. Und ein Tool wäre nötig, das das auch erledigt.
-
hustbaer schrieb:
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.
Das ist aber generell ein Problem, wenn sie die API ändert. Das müsste man auch auf Sourcecode-Ebene beachten. So wie es boost::signals und bosst::signals2 machen. Finde ich dort gut gelöst.
hustbaer schrieb:
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.
Ich sehe darin meistens keinen Grund! Solche großen gängigen Libs zu Verwenden, hat die Lightwight-Philosophie als Grund. Der Coder ist fauel, für jede Plattform eine neue Implementierung zu schreiben, also wird Lightwight geschrieben.
Wenn es mehr Heavywight Code geben würde, würde man weniger externe Libs nutzen müssen. Beispiel: ich brauche in meiner GUI Library kein libjpeg und kein libpng mitliefern oder voraussetzen. Warum? Weil ich heavywight entwickle: ich benutze die Libs die mir schon Windows SDK mitbringt. Wenn ich später auf X11 portiere, muss ich natürlich Aufwand betreiben und die Libs von X11 nutzen und evtl. neuen Code implementieren. Wenn die X11-Plattform kein png und jpeg kennt... Pech! Dann muss natürlich eine zusätzliche Lib hinzugefügt werden.
Genau so verhält es sich mit XML-Parser: Windows SDK bringt zwei XML-Parser mit
1. MSXML
2. XmlLiteIch werde mich hüten, und vom Anwender unter Windows eine zus. XML Library verlangen, wenn ich XML verarbeiten will. Aber ich werde Aufwand haben, in der Linux-Version den Code für den Standard-Linux-XML-Parser zu implementieren.
Xcerces wird dann benutzt, wenn der Library-Entwickler zu "faul" war, per bedingter Compilierung die Windows-Parser zu nutzen.
Sehr provokativ von mir formuliert!
Nicht sauer sein.
-
Deine Vorgehensweise hat allerdings auch einige Nachteile für den Anwender-Programmierer. Nämlich dass er sich nie sicher sein kann, dass das Programm das er mit deiner Library programmiert sich auch auf allen Plattformen gleich verhält. Es sei denn du treibst einen enormen Aufwand, die Unterschiede der verschiebenen Implementierungen die du verwendest "auszumaskieren".
Xcerces wird dann benutzt, wenn der Library-Entwickler zu "faul" war, per bedingter Compilierung die Windows-Parser zu nutzen.
Xerces wird dann verwendet, wenn der Library-Entwickler bestimmte Features benötigt die z.B. XMLite nicht bietet, und er möchte dass seine Library auf Plattform X genau das gleiche macht/kann wie auf Plattform Y.
Ich als Anwender-Programmierer bin z.B. wenig begeistert, wenn die Doku-Sektion die Unterschiede auf verschiedenen Plattformen beschreibt mehr als ein paar Zeilen lang ist (und die darin beschriebenen Unterschiede auch relevant sind).
Auf Windows geht X nicht, auf BSD Y nicht, auf Linux Y und Z nicht -- scheisse, was bleibt denn dann übrig!?!
-
Das mit dem unterschiedlichen Verhalt stimmt. Aber ich benutze Betriebssystem A weil ich dessen Verhalten will. Und ich benutze Betriebssystem B, weil ich dessen Verhalten besser finde. Das ist jedenfalls mein Empfinden, warum es mehrere Betriebssysteme (berechtigt) auf dem Markt gibt. Ich sollte dem Anwender seine Entscheidung zugestehen.
Weiterhin finde ich es nicht gut, wenn ich alles nochmal ausliefere, obwohl das OS schon die Funktionen mitbringt.
Auf Windows geht X nicht, auf BSD Y nicht, auf Linux Y und Z nicht -- scheisse, was bleibt denn dann übrig!?!
Klar, wenn jetzt Windows lediglich XmlLite hätte, und du brauchst mehr XML-Funktionen, dann ist es berechtigt, eine eigene mächtigere Lib zu nutzen, damit man sein Programm überhaupt realisieren kann. Wenn z.B. ein natives GUI-System keine Tabellen kennt, dann muss ich logischerweise die Lücke mit einer fremden Library oder eigenen Implementierung schließen. Oder wenn die native Tabelle z.B. nur Read-only ist, aber beschreibbar sein muss, muss ich sie ebenfalls durch fremde Libs oder eigene Implementierung ersetzen. Oder eine native Tabelle ist bekanntlich im Verhalten nicht das, was man sich darunter vorstellt, dann auch.
Mein Heavywight-Design schließt ja nicht Lightwight-Design aus! Es kann sich wunderbar ergänzen. Ich sage nicht, das man ins offene Messer laufen soll.
Aber seien wir ehrlich, Mainstream-Funktionen sind in den meisten Betriebssystemen schon dabei und seit Jahren erprobt. Egal ob es der TCP/IP-Stack, XML-Parser oder PNG-/JPEG-Decoder ist. Man sollte sich dort zumindest erstmal umschauen und evaluieren. Dann kann man immer noch sagen "Nein, das ist für mich inakzeptabel.".
-
Es hießt übrigens lightweight.
Aber seien wir ehrlich, Mainstream-Funktionen sind in den meisten Betriebssystemen schon dabei und seit Jahren erprobt. Egal ob es der TCP/IP-Stack, XML-Parser oder PNG-/JPEG-Decoder ist.
Aber wozu bedingte Kompilierung, wenn das eine Library für mich machen kann? Die wird ja im Endeffekt auch nichts anderes machen. Enticklungszeit ist teuer, zumindest habe ich mir das sagen lassen. Und es wird auf nicht besonders viel Verständnis stoßen, wenn man erstmal für alle zu unterstützenden Systeme die jeweiligen System-Libraries lernen muss und sich dadurch die Entwicklungszeit verlängert.
Ein C++ Programmierer sollte mit dem Einbinden von Bibliotheken zurecht kommen, so schwer ist es nun auch wieder nicht.
Natürlich ist das Einbinden von Xerces ein Overkill, wenn es lediglich darum geht eine einfache XML Datei einzulesen, da würde man einfach RapidXml nehmen. Man muss halt das richtige Werkzeug für die Aufgabe nehmen. Wie immer eigentlich.
Und wenn kein bereits vorhandenes Werkzeug die Aufgabe zufriedenstellend löst, muss man selbst ran. Vorher meistens nicht.Also zurück zum Thema: Boost als Abhängigkeit fände ich absolut in Ordnung - das hat eh jeder C++ Programmierer drauf.
-
Irgendwer schrieb:
Es hießt übrigens lightweight.
Danke!
Irgendwer schrieb:
Aber wozu bedingte Kompilierung, wenn das eine Library für mich machen kann? Die wird ja im Endeffekt auch nichts anderes machen.
Ich meine auch die ganze Zeit Library-Entwickler, die die bedingte Kompilierung übernehmen. Als Library-Nutzer bzw. Anwendungs-Entwickler profitiere ich dann natürlich davon, mich nicht mehr selber darum kümmern zu müssen. Es geht mir ja nicht um ein Ultimatum, nicht das ich falsch verstanden werde.
Irgendwer schrieb:
Also zurück zum Thema: Boost als Abhängigkeit fände ich absolut in Ordnung - das hat eh jeder C++ Programmierer drauf.
Na, es gibt immer noch Ignoranten in der C++ Community.
Aber ich merke schon an den Antworten, das man einfach Boost als Abhängigkeit setzen kann.
