C/C++ Wie haltet ihr es mit boost & Co ?

[rubricanis]

Der C++11 std bietet zwar einiges aber gerade bei den bread & butter Sachen wie string handling (split, join, trim etc) und manches andere fehlt es dann doch. Ich habe mir daraufhin mal kurz boost angeschaut aber mal ganz abgesehen davon dass das eine riesige Abhängigkeit produziert, erscheint mir das alles ein wenig 'overingenired'. Wie handhabt ihr das in der Praxis? Schreibt ihr den meisten Kram selbst, habt ihr gute Erfahrungen mit boost oder gibt es andere, empfehlenswerte Biblothen, - evtl auch nur in C. Potabilität und Effizens ist mir wichtig, - und natürlich auch Bequemlichkeit.

 

[Rakor]

Für größere Dinge verwende ich im Allgemeinen das Qt-Framework. Das ist zwar auch sehr fett aber du hast wirklich so ziemlich alles an Board was man braucht. Man kann in Qt auch reine CLI-Programme schreiben und darin die gut ausgelegten Klassen von Qt verwenden.

Für kleinere Kleinigkeiten versuche ich eigentlich Abhängigkeiten zu vermeiden und umgehe wenn möglich externe Bibliotheken. Ich denke es hängt seht stark von der genauen Problemstellung ab.

 

[Kamikaze]

Boost ist quasi der Testing-Ground für neue C++ Features. Die RAII Threading-Komponenten von Boost sind z.B. Interface-Kompatibel im C++11 Standard gelandet. Mir wäre es recht wenn da im nächsten C++ Standard noch deutlich mehr kommt.

Außer icu (Unicode) bringt es keine weiteren Abhängigkeiten und ist damit sehr portabel und mit der Lizenz überall einsetzbar.

Das was Du als Overengineering empfindest ist wahrscheinlich die Menge an Features und der intensive Einsatz von Templates und TMP. Das ist jedoch genau das was Dir die gewünschte Effizienz bringt. Denn bei Templates gilt, dass der Compiler alles was nicht genutzt wird wegwerfen kann und möglichst vieles schon zur Compile-time erledigt wird.

 

[rubricanis]

@ Rakor: Interessante Idee! Ich denke zwar z.Z. nicht an ein GUI aber das heißt ja nicht dass das nicht irgendwann ein Thema wird. Ich werde mir das mal anschauen. Pkg search qt5 gibt eine ganze Reihe von libraries an. Kann man die entsprechenden libs einzeln verwenden oder installiert man das gesammte Packet ? Zur Zeit benutze ich allerdings nur den server (DragonFly, kann sich aber ändern). Wie sieht das mit UTF8 Support aus und kann man Ot für OpenSource Projekte auch auf Win/Mac verwenden? Oder ist das inzwischen vollkommen OpenSource? (werde mich umsehen)

@ Kamikaze: Es ist zwar schon einige Jahre her dass ich mit C++ was gemacht habe, aber mit Templates hatte ich keine Schwierigkeiten. Ist ja letztlich auch nichts anderes als eine reichlich kryptische, funktionale Sprache. Mich hat wohl eher die Doku irritiert und ich vermute da muss man sich auch erst einmal hineinlesen muss um die Zusammenhänge zu verstehen. UTF8 ist ein must have, obwohl es da wohl auch einzelene libs gibt.

Schwierige Entscheidung...

 

[rubricanis]

Ich habe mich mal bei Qt umgesehen. Für UI sicherlich eine interessante Option, für mich wohl eher nicht. Mich stört insbesondere der moc. Kann sein dass dass bei UI Sinn macht, sonst wohl eher nicht. Ich werde mir mal boost näher ansehen ...

Danke für Info!

Peter

 

[Rakor]

Ich muss sagen, dass mich moc bisweilen nicht gestört hat. Im Gegenteil, wenn man qmake nutzt hat man mit moc selbst nix zu tun und muss sich nicht die Bohne um Makefiles kümmern weil die automatisch generiert werden... Das ist Luxus pur
Zumal man den Moc meine ich nur braucht wenn man mit QObjects arbeitet (was ich jedoch sehr empfehlenswert finde, da man sich da z.B. keinen großen Kopf um Speicherbereinigung machen muss wenn man etwas sinnvoll mit den Parent-Beziehungen umgeht).

Qt macht intern schon lange UTF-8 und je nachdem was du vor hast kannst du für jeden Stream einfach festlegen was es sein, oder als was es interpretiert werden soll. Die QString-Klasse ist sehr mächtig (meiner Meinung nach). Vernünftig komplilierte Projekte bauen ohne Änderung auf OS X, Windows, Linux, BSD. Nett ist auch, wenn man QSettings z.B. nutzt (und ihm keine Vorgaben macht) speichert der auf WIn automatisch in Registry auf Unix automatisch nach .config und in OS X automatisch in Pref-files. DAS ist Plattformunabhängig Du kannst deine Projekte unter jede Lizenz stellen die du willst (egal auf welcher Plattform). Qt gibts unter diversen offenen Lizenzen und wenn du an Qt selbst schrauben willst kannst du auch ne kommerzielle Lizenz erwerben. Wenn du für mobile Geräte Entwickeln willst bietet die Kommerzielle Version wohl auch einige Vorteile (was ich aber nicht mache). Qt-Libs brauchst du nur die, die du auch verwendest.. Ich nutze gerne den QtCreator als IDE. Der beschleunigt die Entwicklung massiv wie ich finde.

Es ist auf jeden Fall paar Blicke wert

VIel Erfolg und kannst dann ja auch mal deine Boost-Erfahrungen schreiben.

 

[rmoe]

Boost, von durchaus hellwachen sehr fähigen Leuten konzipiert, ist leider dazu verurteilt, Mist zu sein, einfach weil so einiges bei C++ Mist ist, Templates z.B. Da habe ich den Eindruck, das hätte ein besoffener Student auf Crack ersonnen.

Vor etlichen Jahren, OK, da hatte mancher keine andere Wahl als C++. Aber spätestens seit D klar aus dem beta Stadium heraus ist, gibt's doch "C++, aber richtig gemacht".

Letztlich schlägt da mal wieder gnadenlos das Gesetz zu, demzufolge Mist weiter lebt, weil es viele libraries, geschrieben in und für eben diesen Mist gibt. Und damit ziele ich keineswegs auf die C++ Programmierer; dass die "festgezurrt" sind auf ihrer Insel mit einem ziemlich gut sortierten library Wühltisch verstehe ich aus pragmatischer Sicht durchaus.

 

[goblin]

Ich mag boost deswegen schon nicht, weil da extrem viel seltsamer Code in header-files rumschwirrt. Das macht es nahezu unmöglich, den eigenen Code mit einem vernünftigem (damit meine ich hohem ) Warnungs-Niveau zu kompilieren, weil die Warnungen aus dem eigenen Code in der Masse der Warnungen aus den Boost-Headern untergehen.
Dazu kommt, dass manche von diesen Warnungen sehr einfach vermieden werden könnten, da regen mich unnötige Semikoli (oder Semikolons oder was weiß ich wie der Plural ist) auf, die erzeugen mit so gut wie allen Compilern Warnungen im pedantic-mode.
Und ich hab einige Ports, die aufgrund von boost nicht mit clang++36 kompilieren.
Aus diesen Gründen bin ich mir Insgesamt unschlüssig, ob boost wirklich immer den hohen Qualitätsstandards erfüllt, die man den Bibliotheken nachsagt.

Außerdem ist es ein Riesenblock, für kleine Werkzeuge halte ich es für massiv übertrieben, wenn es sich aber um ein größeres, plattformunabhängiges Projekt handelt, dann würde ich mir es eher nochmal überlegen. Insgesamt stehe ich dem aber eher skeptisch gegenüber.

Qt ist zwar eine super UI-Bibliothek, aber erstens auch gigantisch und zweitens geht es nicht ganz so schön mit modernem C++ zusammen.
Und gerade String-Handling ist in Qt zwar sehr bequem, aber auch ziemlich langsam, da ein QString sein Encoding kennt usw.

Bezüglich TMP möchte ich noch hinzufügen, dass das zwar sehr laufzeiteffizienten Code erzeugen kann, aber auch unglaublich speicherineffizienten.
Templates sind nunmal komplette Kopien und erzeugen ziemlich schnell Bloat. Ich hatte damit zwar noch nie Probleme bei den wenigen Projekten, bei denen ich boost eingesetzt habe, allerdings habe ich da auch nie nachgemessen. Aber ich stehe TMP insgesamt recht kritisch gegenüber, weil weder Code noch Fehlermeldungen verständlich sind.

 

[rubricanis]

Boost, von durchaus hellwachen sehr fähigen Leuten konzipiert, ist leider dazu verurteilt, Mist zu sein, einfach weil so einiges bei C++ Mist ist, Templates z.B. Da habe ich den Eindruck, das hätte ein besoffener Student auf Crack ersonnen.

Na gut, schön ist der Syntax nun wirklich nicht, aber so schlimm nun auch nicht, eben Gewöhnungsbedürftig. YMMV

Vor etlichen Jahren, OK, da hatte mancher keine andere Wahl als C++. Aber spätestens seit D klar aus dem beta Stadium heraus ist, gibt's doch "C++, aber richtig gemacht".

Da ist auch nicht alled Gold was glänzt. Ein bißchen netterer Template-Syntax macht es auch nicht. Vielleicht ist DMD aus dem Beta raus, einschließlich propäritärem Kernel, LDC und GDC wohl kaum. Und letztlich hängt das Ganze an 2 Leuten - sicherlich fähigen - aber da ist mir die humane Basis doch zu schmal.

 

[rubricanis]

Templates sind nunmal komplette Kopien und erzeugen ziemlich schnell Bloat. Ich hatte damit zwar noch nie Probleme bei den wenigen Projekten, bei denen ich boost eingesetzt habe, allerdings habe ich da auch nie nachgemessen. Aber ich stehe TMP insgesamt recht kritisch gegenüber, weil weder Code noch Fehlermeldungen verständlich sind.

Die Erzeugung von bloat liegt an einem selbst. Aber ohne Templates ist C++ nicht viel anderes als C+OOP. Und mit OOP habe ich es nicht so. Gut, Fehlermeldungen sind ein ernsthaftes Problem. Bzgl. Warnungen halte ich es mit den Go-Leuten. Entweder ist etwas falsch und dann Abbruch, oder es ist OK. Mal sehen was boost dazu meint...

 

[rubricanis]

Ich muss sagen, dass mich moc bisweilen nicht gestört hat. Im Gegenteil, wenn man qmake nutzt hat man mit moc selbst nix zu tun und muss sich nicht die Bohne um Makefiles kümmern weil die automatisch generiert werden.

Daran habe ich ja noch garnicht gedacht. Meine ersten Versuche mit CMake waren nicht gerade erfolgreich und ich bin froh dass mir Yamagie einen schweren Stein bei gmake aus dem Weg geräumt hat. Da habe ich doch ein bißchen Bauchschmerzen ...

.. Das ist Luxus pur

Wenn du wissen willst was bei einem Build-Tool Luxus ist, mußt du dir Elixir/Mix auf der Erlang/OTP Platform ansehen. Diese ganzen C/C++ Tools leiden darunter dass sie auf dem uralten und verquere C und make beruhen. Leider kommt man um diesen Blödkram nicht herum.

Es ist auf jeden Fall paar Blicke wert

VIel Erfolg und kannst dann ja auch mal deine Boost-Erfahrungen schreiben.

Hmm, das ist alles noch nicht ausgemacht. Ich muss ja kein Geld damit verdienen und kann mir Zeit lassen und mich ein wenig umsehen. Konkret brauche ich z.Z. eh nur besseres String-Handling und vielleicht schreibe ich das erst einmal selbst und experimentiere mit boost/qt ein wenig. Muss mich sowieso mit C++ erst wieder vertraut machen, ist einige Jahre her dass ich damit etwas gemacht habe. Da hakt es noch an einigen recht profanen Ecken...

 

[rmoe]

Es gibt/gab im wesentlichen 3 Wege. Den richtigen, der einfach nur spezifische Objekte erzeugt, die wie alle anderen Objekte auch behandelt, genutzt und instantiiert werden. Den theoretisch interessanten, der sich aber in Experimenten als viel zu teuer, sowohl in Sachen Performance als auch Speicher herausgestellt hat, nämlich wirklich intelligente, versatile metaObjekte zur Laufzeit zu erzeugen. Und den falschen, nämlich den von C++. Wenig Vorteil, wenig wirkliche Flexibilität, viel Brimborium, verstörende (und verstörte) Syntax und reichlich Bürokratie.

Nein, ich hasse C++ nicht. Ich hab's eine ganze Weile benutzt. Nachdem ich es anfangs für die Zukunft hielt. Bis ich wirklich gute, durchdachte Sprachen kennenlernte, die ordentlich implementierten, was C++ immer zu versprechen versprach ...

Anders ausgedrückt: Wenn eine Sprache sperriger (und ähnlich dick standardisiert) ist als Ada, dann sollte man ernsthaft nachdenken.

Kurz zu D: Also, ich habe da schon recht brauchbare Sachen gesehen. OK, den Umfang an Bibliotheken con C++ hat's natürlich nicht und ja, das kern team ist klein aber professionell und sehr erfahren in Sachen Sprachen und Compiler. Auch mein Eindruck beim mal einige Wochen praktisch probieren war sehr positiv. Damit ist man ganz erheblich produktiver als mit C++ oder Java.

Nur kurz zu qt: ich bin nicht so ganz sicher, dass man das auch frei und kostenlos für nicht-open source Sachen verwenden darf (weiss es aber mangels Interesse nicht wirklich).

 

[-Nuke-]

ich halte ja C++ "alleine" für ziemlich unbrauchbar in der heutigen Zeit. (außer für Systementwicklung)

Ohne extra Bibliothek(en) steckt man sehr schnell fest und hier hat man dann die Qual der Wahl. Wie schon gesagt, selbst bei simpler und korrekter String-Verarbeitung ist man schnell an den Grenzen von der STL. C++ mit Boost kommt da schon näher an die Sachen heran, die Systeme wie Java, Python oder Ruby bieten.
Und dann kommt noch die nächste Etappe hinzu -> kompiliere den ganzen Mist jetzt mal o_O Da hast du dann schön plattformunabhängig programmiert und dein Build-System braucht Streicheleinheiten pro System.

Aber ich selbst mag Boost nicht so. Hauptsächlich, weil das Debugging durch massive Template-Nutzung doch arg erschwert wird und die Compilermeldungen auch bei Clang doch arg lang werden.

Da erwische ich mich auch oft an dem Punkt: "Ach scheiß drauf, nimmst'e Python". Da installiert man auf jedem System die Python Runtime, wenn nicht schon drauf und es läuft. Geht natürlich nur, wenn Performance nicht so eine Rolle spielt.

Mit Python eine HTTP-Adresse ansprechen, dort ein XML runterladen, parsen und auswerten sind in Python eine handvoll Zeilen. In reinem C++ ist das ein großes Grauen, mit Boost schon einfacher, aber hier wird dein Build-Skript (oder Skript-Generator) schon länger als dein eigenes Programm...

 

[rubricanis]

Wir brauchen hier nicht alle Sprachen durchzukauen, ich will und brauche C++ da ich mich u.A. mit LLVM beschäftigen will. Punkt. Ocaml, D oder so etwas wäre evtl. noch eine Option. Ich bin zwar ein Sprachenfreak, aber man sollte nicht auf zu vielen Hochzeiten tanzen sonst kommt man nicht weiter.

 

[rmoe]

ich halte ja C++ "alleine" für ziemlich unbrauchbar in der heutigen Zeit. (außer für Systementwicklung)

Ohne fies sein zu wollen: Aber auch das ist mehr "Allgemeinwissen" (sprich: Ammenmärchen) als Realität.

Für Systementwicklung wie in "kernel, Treiber und Konsorten) ist C++ zu fett, zu kapriziös und zu mittelbar. Unten im Keller brauche ich Unmittelbarkeit, da muss ich eine Sprache wie einen Meta-Assemblernutzen können (also z.B. C); ein kapriziöser Code Generator wie C++ wird da schnell zum Problem (siehe z.B. aktuellen strcmp thread).

Für Systementwicklung wie in "größere System tools" wäre OO manchmal wirklich nützlich, ja, aber doch nicht die Mischung aus Gestrüpp und Minenfeld von C++. Da ist ja fast alles besser als C++ und so manches, z.B. von Wirth, Meyer, Ichbiah, ist sogar dimensional besser. Wirklich begeistert bin ich da auch von D nicht, aber es ist allemal viel besser als C++ (siehe auch -> "C++ richtig gemacht".

Und was LLVM angeht, so ist man da keineswegs auf C++ festgelegt. Nur haben die halt so ziemlich alles (Doku, Beispiele, etc) auf C++ getrimmt. Und, wie gesagt ich will nicht fies sein, aber ich will auch nicht nett lügen: wenn ich ein Compiler Front End nicht selbst hinkriege sondern auch dazu gerne LLVM nutzen und vielleicht bisschen zurechtstricken will, dann sollte ich mich vielleicht fragen, ob Compilerbau das Richtige für mich ist.

 

[rubricanis]

Und was LLVM angeht, so ist man da keineswegs auf C++ festgelegt. Nur haben die halt so ziemlich alles (Doku, Beispiele, etc) auf C++ getrimmt.

Eben!

Und, wie gesagt ich will nicht fies sein,...

Bist du aber, - macht aber nichts! Brauchst du nur nicht immer wieder zu erwähnen.

..: wenn ich ein Compiler Front End nicht selbst hinkriege sondern auch dazu gerne LLVM nutzen und vielleicht bisschen zurechtstricken will, dann sollte ich mich vielleicht fragen, ob Compilerbau das Richtige für mich ist.

Du mußt nicht unterstellen dass andere die gleiche Motivation für so etwas haben wie vielleicht du. Ein Frontend ist nun wirklich nicht das große Problem, aber das heißt ja nicht dass die Techniken die bei LLVM verwendet uninteressant sind, z.B. die Optimierungen, wie das Ganze implementiert ist uvm. Ich finde das Projekt einfach interessant, das ist alles.

Ob ich damit jemals etwas anfange weiß ich nicht, und interessiert mich auch jetzt nicht. Reine Neugier, Spieltrieb wenn du so willst, homo ludens und so ... Ich verstehe ja dass Profis da anders denken (müssen), aber so ist es nun einmal.

 

[rmoe]

Bist du aber, - macht aber nichts! Brauchst du nur nicht immer wieder zu erwähnen.

Nein, fies geht anders (und verfolgt andere Absichten). Übrigens versuche ich durchaus, Dinge so zu formulieren, dass sie niemanden verletzen.
Nur: Es gibt halt nun mal auch in unserer Branche eine Menge Mist, Halbwahrheiten, Propaganda, eher politisch oder sozial motivierte Credos, usw. und ich möchte da nicht mit tanzen.

Was du da machst (homo ludens), also das spielerische Experimentieren, finde ich durchaus gut. Zum Problem wird das nur, wenn - wie erschreckend oft - sowas dann plötzlich auf sourceforge oder so landet und plötzlich als ernst zu nehmendes Projekt betrachtet (und propagiert) wird.

Geht man den teilweise erschreckenden Sicherheitsmängeln, die man durchaus auch in kritischer Infrastruktur findet, mal nach, so findet man *sehr häufig* eine von zwei Komponenten: Ein Bastler, der nicht wirklich verstanden hat, was er da gemacht hat; Firmeninteressen wie "Scheiss auf Fehler verbessern, neue features müssen her!" oder auch "wir müssen unser Zeug verteidigen gegen Konkurrenz" oder ...

Wobei die Inkompetenz oft ganz schlicht und ordinär damit beginnt, dass jemand Sprache X verwendet hat, weil er die cool fand und all seine Kumpels auch, oder weil irgendein open source "Guru" das zur ultimativen Sprache erklärt hat, oder ...

 

[rubricanis]

Was du da machst (homo ludens), also das spielerische Experimentieren, finde ich durchaus gut. Zum Problem wird das nur, wenn - wie erschreckend oft - sowas dann plötzlich auf sourceforge oder so landet und plötzlich als ernst zu nehmendes Projekt betrachtet (und propagiert) wird.

Da brauchst du keine Sorge haben...

Terra war der Grund mich mit LLVM zu beschäftigen. Find ich interessant. Kompiliert leider nicht unter bsd da bsd von LuaJIT nicht unterstützt wird.