Ist boost tod?
-
Warum kommt da keine neue offizielle Version mehr raus seid Januar?!
-
Die Sockets scheinen auch nicht wirklich voranzukommen...
-
Benutzt eigentlich irgend jemand boost in kommerzieller Software? Teilweise kommt mir diese Lib nur wie eine akademische Spielwiese vor
-
ehrlich gesagt hab ich bis jetzt auch nichts gefunden das für mich sinnvoll gewesen wäre..
-
Dann würd ich Dir dringend empfehlen mal reinzuschaun.
Hast Du mal irgendne Datei parsen müssen? Spirit ist da echt cool, auch wenn man ne Weile braucht um durchzusteigen.
-
kurze frage:
was is boost???
noch nie was von gehört
-
"... free peer-reviewed portable C++ source libraries. The emphasis is on libraries which work well with the C++ Standard Library."
-
Boost ist sehr aktiv, in den letzten Monaten sind einige neue Dinge hinzugekommen. Okay, die Sockets lassen leider immer noch auf sich warten. Aber von "tod" zu sprechen, ist irgend wie komplett verfehlt.
Benutzt eigentlich irgend jemand boost in kommerzieller Software?
es gibt ja sogar eine Firma, die nichts anderes tut, als boost mit kommerziellem Support zu versehen. Also wird das wohl schon genutzt werden
http://www.boost-consulting.com/
-
DocJunioR schrieb:
ehrlich gesagt hab ich bis jetzt auch nichts gefunden das für mich sinnvoll gewesen wäre..
Was kann man denn schreiben, wo Smart Pointer und function<> einem nicht helfen können?
-
kingruedi schrieb:
Aber von "tod" zu sprechen, ist irgend wie komplett verfehlt.
Stimmt. Es heißt "tot"
-
operator void schrieb:
DocJunioR schrieb:
ehrlich gesagt hab ich bis jetzt auch nichts gefunden das für mich sinnvoll gewesen wäre..
Was kann man denn schreiben, wo Smart Pointer und function<> einem nicht helfen können?
Und regex!
utility ist auch oft interessant.
thread natürlich auch.
call_traits sind praktisch.
date_time ist nützlich, wenn man mal mit nem Datum umgehen muss.
und signal ist auch des öfteren nützlich.Diese Teile von boost kann man durchaus öfter brauchen. Auch sind sie nicht übermäßig komplex, wie zB spirit (wo man sich längere zeit einarbeiten muss, und deshalb abschreckt).
boost bei hand zuhaben ist nicht schlecht - ohne geht es natürlich auch, aber boost ist manchmal einfach praktisch.PS: wie konnte ich nur concept_check vergessen...???
-
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.
