Boost - Stiltechnische Meinungen gesucht

PuerNoctis

Heyho allesamt,

ich möchte hier mal gerne einige Meinungen von Euch zur Verwendung der Boost-Libraries einholen. Ein super Kumpel von mir ist begeisterter Boost Nutzer, was ich selbstverständlich verstehen kann, da die Libs von Leuten geschrieben wurden, die wirklich einiges auf dem Kasten haben, und die Standardlibraries um sinnvolle, und vor Allem effiziente, Funktionen erweitert werden. So gut, dass meines Wissens sogar einige Dinge in den neuen C++ Standard einfließen sollen.

Allerdings.... ich weiß nicht, ich habe in letzter Zeit das Gefühl, dass er das etwas zu pragmatisiert angeht, und denkt alles was nicht-Boost implementiert wurde, schlichtweg scheisse ist. Ich will ihm hier aber nix unterstellten falls er es zufällig liest, man bekommt nur langsam den Eindruck, weil seine Begeisterung dafür in jedem zweiten Gespräch schon ziemlich stark durchkommt

Ich persönlich stehe Boost relativ neutral gegenünber. Die Verwendung kann in vielen Fällen bestimmt sinnvoll sein, aber wenn ich das gleiche Ergebnis zu mehr oder minder gleicher Performance erreiche (z.B. boost::thread <=> pthread_*), dann schreibe ich mir den Part halt gleich selber. Weiter habe ich hierbei wenigstens das Gefühl, meinen Horizont zu erweitern, Anwendungstechniken und Abläufe zu erlernen, anstatt vorgebackene Bausteine aneinander zu reihen (beschränkt sicher aber nicht nur auf Boost). Wenn ich dann weiß wie etwas bestimmtes im Detail praktisch funktioniert, kann ich ja gerne fertige Frameworks o.Ä. verwenden, wenn ich mal zu Faul bin alles per Pedes zu machen. Aber wenn ich keinen Plan habe, was da eigentlich passiert, dann hab' ich da irgendwo eine gewisse Abneigung gegen solche fertigen Libraries und verwende sie eher halbherzig...

Das klingt jetzt alles vielleicht etwas naiv, aber mir fehlt dann irgendwo dieser gewisse "Ah, so funktioniert das"-Effekt. Klar, könnte mir direkt den Code anschauen, aber so richtig verstehen wird man's erst, wenn man sowas auch mal gemacht hat.

Meine persönlich Meinung ist: Boost ist schon fein, aber es sollte dann nicht mit Kanonen auf Spatzen geschossen werden, und wenn ich nicht weiß wie Boost das macht was es macht, probier' es erstmal selber.

Ich bedanke mich für jede Meinung und Ansicht zu dem Thema, und würde mich über Rege Diskussionsteilnahme freuen

Mfg
PuerNoctis

LordJaxom

Weiter habe ich hierbei wenigstens das Gefühl, meinen Horizont zu erweitern, Anwendungstechniken und Abläufe zu erlernen, anstatt vorgebackene Bausteine aneinander zu reihen (beschränkt sicher aber nicht nur auf Boost).

Im privaten Umfeld und zu Studienzwecken kannst Du das sicher machen, da sind Lerneffekte ja auch erwünscht. Wenn Dein Arbeitgeber von Dir verlangt, eine Lösung zu präsentieren, wirst Du eine eigene Lösung mit Entwurf, Implementierung und (!) Test kaum so schnell einsetzen können wie die bereits implementierten und getesteten Boost-Pendants.

Wenn ich dann weiß wie etwas bestimmtes im Detail praktisch funktioniert, kann ich ja gerne fertige Frameworks o.Ä. verwenden, wenn ich mal zu Faul bin alles per Pedes zu machen.

Das hat mit Faulheit überhaupt nichts zu tun. Effizient ist das Stichwort.

Aber wenn ich keinen Plan habe, was da eigentlich passiert, dann hab' ich da irgendwo eine gewisse Abneigung gegen solche fertigen Libraries und verwende sie eher halbherzig...

Wobei das nicht-, oder unvollständige Verwenden von Bibliotheken auch auf "keinen Plan" hindeuten könnte

Selber entwickeln birgt die Gefahr von Fehlern. Ein Arbeitgeber will funktionierende Lösungen haben. Und wenn man etwas selber entwickelt, sollte das einen guten Grund haben. Das kann z.B. sein, das es einfach noch keine Lösung auf dem Markt gibt. Oder die Lösungen sehr schlecht sind. Oder sich nicht den eigenen Bedürfnissen anpassen lassen.

Zum Lernen kann und sollte man wirklich auch etwas selber designen und implementieren. Aber hier auf Arbeit versuche ich immer das zu benutzen, was andere erfolgreich schon umgesetzt und von vielen anderen eingesetzt wurde. Um so mehr menschen etwas schon eingesetzt haben, um so mehr wurde es (unfreiwillig) getestet. Meine eigene Komponente würde im schlechtesten Fall nur ich eingesetzt haben.

LordJaxom schrieb:

Aber wenn ich keinen Plan habe, was da eigentlich passiert, dann hab' ich da irgendwo eine gewisse Abneigung gegen solche fertigen Libraries und verwende sie eher halbherzig...

Wobei das nicht-, oder unvollständige Verwenden von Bibliotheken auch auf "keinen Plan" hindeuten könnte

"Oh, du hast ja hier hansi::vector implementiert. Warum das?"
"Weil ich einen vector brauchte!"
"Ehm, aber du weißt schon, das es std::vector gibt?"
"Echt? Kannte ich garnicht!"

Alles andere bräuchte eine sehr gute Begründung, warum man nicht std::vector benutzt.

rüdiger

@PuerNoctis
Wenn du wirklich Software veröffentlichen willst, solltest du eher Boost benutzen, da die Bibliotheken eine sehr hohe Qualität haben und viele Fehler und Bugs beseitigt wurden. Oft übersieht man Kleinigkeiten - vor allem etwas zur Exceptionsicherheit - und das sind dann die schlimmsten Bugs! Treten eigentlich nie auf, nur wenn es wirklich kritisch ist :). Und ich glaube nicht, dass die meisten Leute hier (selbst erfahrene!) zB auf Anhieb einen fehlerfreien shared_ptr oder thread-lib hinbekommen werden.

Aber natürlich gibt es auch bei Boost Bereiche die nicht gut sind. Aber im Endeffekt ist das meiste sehr gut getestet und auch schon seit mehreren Jahren dabei.

(Außerdem sind die Boostsachen ja zT auch Inspiration für den neuen Standard bzw. TR2).

pumuckl

Alles zu verteufeln was nicht boost heißt ist sicherlich mehr als übertrieben. Für verschiedene Aufgaben gibt es verschiedene Werkzeuge, manchmal gibts für eine Aufgabe auch mehrere Werkzeuge. Boost ist nicht mehr und nicht weniger als eine Sammlung von (meistens) recht guten Werkzeugen, die aber erstens nicht für alle Aufgaben geeignet sind und die zweitens nicht zwangsweise immer das Beste Mittel für eine bestimmte Aufgabe darstellen.
Was das selbstentwickeln vs. Bibliothek benutzen angeht: Eine Bibliothek nicht zu benutzen weil man ihr Interface nicht versteht ist richtig. Da ist es aber immer leichter die Doku zu lesen und danach die Bibliothek richtig zu benutzen als alles selbst zu schreiben (von den bereits erwähnten Fehlern mal ganz abgesehn). Eine Bibliothek nicht zu benutzen weil man nicht weiß was im Inneren vor sich geht ist gelinde gesagt Blödsinn und geht am Sinn einer Bibliothek vorbei. Stichwort Kapselung - es ist gerade Zweck der Sache dass man sich NICHT um die Innereien kümmern muss.

Shade Of Mine

Zum lernen ist der Ansatz die Bibliotheken selber zu implementieren aber super und genau das richtige!

pumuckl

Shade Of Mine schrieb:

Zum lernen ist der Ansatz die Bibliotheken selber zu implementieren aber super und genau das richtige!

Aber ausschließlich zum Lernen, nicht um produktive Software zu schreiben.

Dravere

Zu den bisher alles sehr sinnvollen Posts, möchte ich noch etwas dazufügen. Boost hat wohl irgendwie einen falschen Namen ausgesucht, ich höre das nun schon zum fünften mal von jemanden:

PuerNoctis schrieb:

Die Verwendung kann in vielen Fällen bestimmt sinnvoll sein, aber wenn ich das gleiche Ergebnis zu mehr oder minder gleicher Performance erreiche (z.B. boost::thread <=> pthread_*), dann schreibe ich mir den Part halt gleich selber.

Boost, obwohl der Name nach Performance klingt, hat wirklich nichts mit der Performance zu tun. Eine Boost Bibliothek garantiert nicht, dass sie schneller laufen wird, als andere Bibliotheken. Hierzu auch ein Auszug aus der FAQ:

Where does the name "Boost" come from? Boost began with Robert Klarer and I fantasizing about a new library effort over dinner at a C++ committee meeting in Sofia Antipolis, France, in 1998. Robert mentioned that Herb Sutter was working on a spoof proposal for a new language named Booze, which was supposed to be better than Java. Somehow that kicked off the idea of "Boost" as a name. We'd probably had a couple of glasses of good French wine at that point. It was just a working name, but no one ever came up with a replacement. (Beman Dawes)

Um dein Beispiel mit pthread und boost::thread aufzugreifen, wo ist der Unterschied der beiden Bibliotheken? pthread ist für C gemacht, boost::thread für C++, dementsprechend unterscheiden sich die Interfaces. Mit boost::thread kann man zum Beispiel auf ganz einfach Art, eine nicht statische Memberfunktion aufrufen. Bei pthread resultiert dies in eine riesige Frickelei, wo dann die Argumente der Leute, welche vor mir gepostet haben, eintreten. Es entstehen Fehler.
Im übrigen, auf Unix System kapselt boost::thread pthread , soweit ich mich erinnere, also sollte das nochmals verdeutlichen, um was es bei boost::thread geht.

Grüssli

asc

PuerNoctis schrieb:

Allerdings.... ich weiß nicht, ich habe in letzter Zeit das Gefühl, dass er das etwas zu pragmatisiert angeht, und denkt alles was nicht-Boost implementiert wurde, schlichtweg scheisse ist.

Vielleicht mag das für dich auch boost-Orientiert klingen: Wenn es eine Funktionalität gibt die entweder im Standard oder in einer Standardnahen Implementierung (wie boost) existiert, ziehe ich diese immer einer selbstgeschriebenen vor, es sei den ich weiß definitiv gute Gründe dagegen.

a) Selbst wenn ich QS recht hoch schätze, werde ich niemals die Zeit/Ressourcen haben um Tests in dem Umfang durchzuführen, wie es in solchen Bibliotheken der Fall ist.

b) In der Regel sind die Umsetzungen recht durchdacht, und man kann seinen Code ggf. auch leichter portieren (Dies mag kein Thema sein, ich finde es aber beruhigend wenn man sich nicht 100% an eine Plattform bindet).

c) Ich laufe selbst von Zeit zu Zeit Gefahr das Rad an der ein oder anderen Stelle neu zu erfinden, die Verwendung solcher Bibliotheken verhindert dies ein wenig.

d) Ich habe bei einem Jobwechsel eine geringere Einlernphase wenn beide die gleichen Bibliotheken verwenden (Und sowohl bei der Standardbibliothek als auch Boost ist die Wahrscheinlichkeit im C++ Umfeld nun wirklich nicht gering)...

e) Auch wenn die Bibliotheken nicht zwangsweise nur auf Performance ausgelegt sind, so ist die Wahrscheinlichkeit recht hoch, das sie besser optimiert als eigene Lösungen sind.

Du hast in der heutigen Zeit nicht die Zeit alles neu zu erfinden. Ja, ich verstehe gerne was sich hinter den Kulissen in etwa abspielt, aber ehrlich gesagt muss dieses Verständnis nicht zwangsweise bis auf Ebene der Implementierung existieren. Mir reicht es an manchen Stellen auch, wenn ich grob weiß wie etwas funktioniert (z.B. habe ich nur ein Grundverständnis für die Templatemetaprogrammierung, das reicht mir aber bislang auch, da ich auf einer höheren Ebene Programmiere [Anwendungssoftware]).

cu André