Ist boost tod?
-
LOL
gerade wo man sich nach dem Tod fragt kommt ein neues Release nach 9 Monaten
Coming soon - Version 1.32.0
[October, 25] A long-awaited Boost release packed with new libraries, features and bug fixes is expected to be released by the end of this week.
-
Meiner Meinung nach findet boost wenig Einsatz, wenn man z.B. andere große Libs bereits im Einsatz hat. Da fällt mir spontan Qt, wxWidgets, MFC u.a. ein. Die genannten Dinge wie Threads, Signals usw. sind in irgendeiner Weise irgendwie bereits in den anderen Libs vorhanden. Man sollte sich fragen, warum? Weil die anderen Libs (korrigiert mich bitte) nunmal schon vorher da waren
Was wäre, wenn z.B. boost vor den oben genannten Libs existiert hätte? Diese Libs hätten doch eindeutig auf boost aufgesetzt.
boost ist doch aber bestimmt dort im Einsatz, wo man die oben genannten Libs nicht im Einsatz hat.
-
Achja, bisher benutze ich shared_ptr<> aus boost. Ist wirklich das einzige bisher, was ich in den anderen Libraries so nicht finde was ich für mich brauche. Würden die anderen Libs sowas haben, bräuchte ich kein boost.
-
Artchi, nicht das wer-war-zu-erst-da entscheidet über den nutzen eines Produktes im Allgemeinen. Boost ist von der Codequalität einfacherer gehalten, was natürlich nicht impliziert dass es dadurch auch schlechter ist. Für die QT Libs benötigst du zum beispiel QtN(1-3) Libraries. Boost ist gerade mal ein paar KB oder MB groß. Während bei QT im Header QT-thread noch einiges an anderen Müll im Code hausiert, ist Boost-Thread eindeutig sauberer gehalten. Im wahrsten Sinne des Wortes enspricht der Code dem Headernamen.
-
Artchi schrieb:
Meiner Meinung nach findet boost wenig Einsatz, wenn man z.B. andere große Libs bereits im Einsatz hat. Da fällt mir spontan Qt, wxWidgets, MFC u.a. ein. Die genannten Dinge wie Threads, Signals usw. sind in irgendeiner Weise irgendwie bereits in den anderen Libs vorhanden.
Ich würde dennoch boost nehmen, sofern es ohne große Probleme machbar ist. Auch würde ich versuchen von QString und Co wegzukommen und sei es nur der Performance wegen
Aber man bleibt einfach unabhängiger
Allerdings habe ich auch einige Punkte aufgezählt die wirklich nützlich sind und die nur boost hat.
-
btw:
das Problem von dem langsamen fortschreiten von boost liegt in der struktur.Die einzelnen Libraries sind größtenteils eigenständig. Aber boost wird nur als ganzes released. dh, dass zB Spirit und mpl schon einen neuen Release haben, aber das Python Bindung noch länger braucht - und es gibt keinen boost release.
Sowas ist natürlich doof. Allerdings ist boost schon mature genug um soetwas zu verkraftet - doof ist es nur, wenn man auf bestimmte features wartet, aber dann kann man ja den CVS code nehmen...
-
Ich warte auf Sockets.
Allerdings ist bei denen anscheinend jetzt schon zu lange nichts mehr vorangegangen, diese Hoffnung habe ich jedenfalls inzwischen mal begraben.
-
Boost::Sockets gibt es als CVS im Betastadium.
-
Naja, C++ kennt kein Currying, deswegen ist man doch auf sowas, wie boost::bind unf boost::function angewiesen. Boost kennt keine discriminated Unions und Pattern-Matching, deswegen ist man doch auf sowas, wie boost::variant angewiesen.
Wenn man solche Features nie nativ in einer Sprache kennengelernt hat wird man sie auch nicht vermissen, da man nichtmals weiß, wie man sie richtig einsetzt. Man muss eben machmal auch wass anderes, als C++ machen, um C++ "besser" zu können.
-
interpreter schrieb:
Benutzt eigentlich irgend jemand boost in kommerzieller Software? Teilweise kommt mir diese Lib nur wie eine akademische Spielwiese vor
OpenOffice.org schrieb:
Future versions of StarOffice software, beginning with 6.0, have been built using the OpenOffice.org source, APIs, file formats, and reference implementation.
Und OpenOffice benutzt boost, also das kommerzielle StarOffice auch.