3. Boost vs. QT

Boost vs. QT

  • ?

    l'abra d'or schrieb:

    um dir zu zeigen, dass man bei ordentlich gesteckten Zielen BEVOR man losprogrammiert, einige Probleme im Vorfeld vermeiden kann, und dazu gehört auch "Kann die Software auf System XYZ laufen?".

    Ich weiß nicht, ob er es nicht kapieren kann oder will (der Nick bietet allerdings Raum für Spekulationen).

    Auf alle Fälle wäre es besser, wenn er NIE Software für Geld entwickeln würde. Dann gäbe es zwei Möglichkeiten: seine Chefs bekommen mit, was er für einen Mist baut und schmeißen ihn raus (dann dürfen andere seine Designfehler ausbaden), oder sie tun es nicht und gehen mit ihrem Produkt so richtig baden.

    @Pumuckl: es geht hier um das Thema Boost/Qt, auch wenn die beiden Worte derzeit nicht fallen ist exakt dieses Thema Gegenstand des Gesprächs - nur momentan halt auf Ebene grundsätzlicher Designfragen.

    0
  • ?

    Um nochmal zum Thema zurück zu kommen:

    Der Linker linkt bei Qt natürlich nur die Teile, die genutzt werden. Wenn Du nur die QTConainter nutzen willst, werden die Threads nicht gelinkt - auch wenn die in derselben lib stehen.

    Zum Speicherbedarf: Das hat nicht nur Platz sondern auch Laufzeitgründe. S. "What every programmer should know about memory". Es spielt heute umso mehr eine Rolle, wenn Apps Multithreaded auf Multicores laufen. Eine über den gesamten Hauptspeicher "verschmierte" Datenstruktur läßt sich nur schwer multithreaded und performant verarbeiten weil ständig die caches geflusht werden müssen.

    Jedes MB zählt! Und das gilt für C++ genauso wie für Java, für den Client und den Server, ...

    0
  • C

    Also ich kann dir nur raten Qt für GUI und boost für die anderen Sachen das mach ich genau so weil es einfach besser ist wenn man später mal eine andere GUI benutzen möcht kann man sie einfacher wechseln. Boost ist in meinen Augen nützlicher als die Libs von Qt.

    Das ist jetzt meine Meinung.

    Grüße,
    Nico

    0
  • E

    Boost ist in meinen Augen nützlicher als die Libs von Qt.

    Okay. Wieso?

    0
  • ?

    Es ist klar, dass Qt bei weitem der Boost Bibliothek überlegen ist, da sie eine vollständige und einheitliche Lösung von Standardaufgabenstellungen liefert. Dabei ist Qt seit langer Zeit keine Framework für GUI Entwicklungen, sondern ein Applikationsframework, während Boost eine Ansammlung von diveresen Bibliotheken ist. Qt ist einfacher zu verwenden, weil sie Polymorphismus, und nicht wie bei Boost, den generischen Ansatz verfolgt, was für die meisten Programmierer einfacher ist. Gerade Missachtung bzw. Nichtverwendung von Polymorphismus bei Boost ist für mich ein K.o. Kriterium für eine moderne objekt-orientierte Bibliothek. Durch den modularen Aufbau lässt sich Qt sehr gezielt verwenden, ist, was Portabilität angeht, auf jedem Fall auf dem Niveau von Boost, ist offen, liefert ein absolut vollständiges Packet für Anwendungsentwicklung und nicht zuletzt spricht nichts dagegen, Boost innerhalb der Qt-Applikation zu verwenden...

    0
  • L

    lepsai schrieb:

    Es ist klar, dass Qt bei weitem der Boost Bibliothek überlegen ist

    Es ist nicht klar sondern deine Meinung 😉

    da sie eine vollständige und einheitliche Lösung von Standardaufgabenstellungen liefert.

    Die da wären? Qt bastelt halt (aus historischen Gründen) recht viel selber an der STL vorbei. Eigene Streams, eigener String, eigene Container (die beiden letzten nutzen im Gegensatz zur STL implicit sharing, war aber nicht der Hauptgrund für eigene Container/Strings).

    Dabei ist Qt seit langer Zeit keine Framework für GUI Entwicklungen, sondern ein Applikationsframework, während Boost eine Ansammlung von diveresen Bibliotheken ist.

    Ja, aber boost hat bestimmte Coding-Guidelines, so dass es beim Verwenden nicht auffällt, dass die einzelnen Teile von verschiedenen Programmieren stammen. Außerdem kann man problemlos einzelne Komponenten miteinander verbinden.

    Qt ist einfacher zu verwenden, weil sie Polymorphismus, und nicht wie bei Boost, den generischen Ansatz verfolgt, was für die meisten Programmierer einfacher ist. Gerade Missachtung bzw. Nichtverwendung von Polymorphismus bei Boost ist für mich ein K.o. Kriterium für eine moderne objekt-orientierte Bibliothek.

    Auch boost setzt auf Polymorphie! Während es bei Qt die Laufzeit-Polymorphie (LP) ist, setzt boost auf Compilezeit-Polymorphie (CP). Dass LP jetzt besser ist als CP ist mir neu! LP hat einen gewissen Laufzeit-Overhead, den CP vermeidet. Vor allem versteh ich nicht, dass LP modern und CP dann wohl überholt ist - schau mal was für templates alles an neuen wunderbaren Sachen in C++0x kommen wird (leider hat es concepts nicht geschafft, AFAIK) - setzt C++ auf ein totes Pferd?
    virtual muss genauso wie templates erstmal verstanden werden. Wenn man voll in die Metaprogrammierung einsteigen will, ist das sicher härter als mit virtual rumzubasteln, aber der normale Anwender sollte bei der Verwendung von boost nicht wirklich viel vertehen müssen. Aber auch virtual gehört verstanden, kann lustige Probleme verursachen 😉

    Durch den modularen Aufbau lässt sich Qt sehr gezielt verwenden

    In meinen Augen ein größeres Plus für boost, denn dort kann ich mir aus den vielen "Mini"-Libs die aussuchen die ich will, bei Qt muss ich immer das komplette Modul (core/gui/xml(patterns)/...) mitschleppen - boost ist "gezielter" als Qt.

    Ein Blick in die boost/qt-Doku verrät: die Schnittmenge der beiden ist recht gering (wurde auch schon gesagt). Deshalb kann Qt eigentlich nicht besser sein als boost. Qt zieht aber einiges an zusätzlichen Abhängigkeiten an. Wenn klar ist dass das ein reines Qt-Projekt wird, ist es mMn. auch kein Problem, gleich alles mit QSocket, QString usw. zu durchziehen. Ist das nicht sicher, sollte ein Blick in Richtung boost (oder sonst eine Lib) gewagt werden, dann braucht das Programm später nicht Qt und wxWidgets oder einen kompletten rewrite.

    0
  • R

    Boost vs QT:

    Qt-Container setz ich nur ein, wenn ich die QT(Als GUI) in dem Modul eh scho verwende.
    Nur wegen den QT-Containern ein ansonsten unabhängiges Modul von den QT dlls abhaengig machen, das wird von der Pflege her fast Selbstmord.
    Wenn mal Module programmiert hasst, mit QT abhaengigkeiten, die mit anderen Modulen im Selben Programm residieren, die von anderen entwicklern kommen, und auch QT Abhaengigkeiten haben, und die Anwendung selber Implementiert auch noch die Gui mit QT, dann weisst wovon ich red 🙂
    Iss ganz lustig wenn sich mehrere Firmen zusammensetzen muessen um sich ueber eine globale QT version inclusive zu vermeidende Compilerflags zu einigen.

    QT Versionen sind nicht 100% binaerkompatibel. Sobald Du nen groesseren Sprung drinne hasst, 4.5.x auf 4.6.x z.b. wars dass ... und die dlls heissen trotzdem gleich !
    Und nen update auf ne hoehere Version kann nem Unternehmen schon mal paar Euronen kosten.

    Spaetestens ab dann liebst du QT freie Module oder linkst die QT nur noch statisch ^^
    boost, zumindest die meisten teile die ich oefters brauch, sind header implementiert, und werden beim includieren meist automatisch statisch zucompiliert und gelinkt, also fast problemlos.

    Ansonsten:

    Der Vorteil der Qt ist das "userfreundlichere" "java like" Interface.
    Der Nachteil, zu gunsten besserer Performance einer naiven verwendbarkeit, ist das das Verhalten der Qt weniger genau spezifiziert und vorhersehbar ist.

    Implizietes sharing der Daten z.b.
    Fuer naive verwendung bringt das nen massiven Performance schub in gewissen situationen.
    Der Nachteil, es werden weniger Zusagen gemacht, so ist laufzeitverhalten oft nicht genau definierbar.
    Wenn man also mehr lowlevel und mehr mit multithreading und mehr selber auf bestimmte faelle optimieren muss, ist die boost und die stl besser geeignet.

    Ciao ...

    0
  • ?

    @l'abra d'or

    zum Thema Vollständige und einheitliche Lösung:
    1. Basiskonstrukte (Strings, Filesystem, Time, Threading, Object-Interkommunikation, Metainfos, Bestriebssystem-Services, usw.)
    2. High-Level Abstraktionen z.B. Datenbankwrapper, Netzwerk, XML support, Test-Framework
    3. Vollständiges GUI-Framework, inkl. UI-Designer, Meta-Compiler und volle Palette von Standardwidgets

    Die Qt API ist sehr elegant und sehr einheitlich, man sieht, dass darauf großer Wert gelegt wird.

    Was Polymorphie angeht, habe ich nicht gesagt, dass LP besser oder moderner ist als CP (was sowieso subjektiv wäre), sondern dass Boost nur eine Variante, nähmilch CP verwendet. Und das ist falsch, weil je nach Use-Case bietet die Mischung aus beiden Möglichkeiten das optimale Ergebnis. Zu sagen, dass "das richtige" C++ soll nur CP verwenden, ist Quatsch, weil LP der wichtigste Baustein einer OO-Sprache ist. Man könnte sogar sagen, dass Anwendung von LP ist ein Grundvoraussetzung beim objekt-orientierten Design.

    Übrigens, auch der Vorwurf, Qt entwickelt sich an STL vorbei, kann man nicht wirklich gelten lassen, da z.B. Qt-Container STL-kompatibel gehalten werden.
    Ausserdem muss ich anmerken, dass Qt STL komplett überflüssig macht, aber das nur am Rande. Sicherlich kann man spezifische Boost-Bibilotheken in Qt-Kontext verwenden - es spricht sicherlich nichts dagegen, aber komplett auf Boost aufzubauen, halte ich persönlich für falsch.

    Gruß

    0
  • Administrator

    lepsai schrieb:

    Die Qt API ist sehr elegant ...

    Bin ich froh, dass so eine Meinung subjektiv ist 🙂

    lepsai schrieb:

    Was Polymorphie angeht, habe ich nicht gesagt, dass LP besser oder moderner ist als CP (was sowieso subjektiv wäre), sondern dass Boost nur eine Variante, nähmilch CP verwendet.

    Dann hast du keine Ahnung von Boost. Boost setzt viel auf CP, aber nicht ausschliesslich. Grundsätzlich macht Boost eine ziemlich ausgeglichene Sache.

    lepsai schrieb:

    Zu sagen, dass "das richtige" C++ soll nur CP verwenden, ist Quatsch, weil LP der wichtigste Baustein einer OO-Sprache ist. Man könnte sogar sagen, dass Anwendung von LP ist ein Grundvoraussetzung beim objekt-orientierten Design.

    Halte ich für eine verkehrte Aussage. Wieso sollte CP keine richtige Polymorphie sein?

    lepsai schrieb:

    ..., aber komplett auf Boost aufzubauen, halte ich persönlich für falsch.

    Bei einer Konsolenanwendung käme ich nicht im Traum auf die Idee, Qt zu nehmen.
    Aber auch sonst meide ich eher Qt, weil ich eben nicht der Meinung bin, dass Qt vieles elegant löst. Ich bin eher der Meinung, dass Qt die Dinge sehr altmodisch löst. Aber das ist eben, wie zu Beginn erwähnt, eine subjektive Meinung.

    Grüssli

    0
  • ?

    Ich habe beruflich mit einer Applikation (1,5MLoC), die auf Qt setzt zu tun. Grundsätzlich sind die meisten Sachen, die man braucht drin, aber:

    * Warum Qt Container verwenden und nicht die Container der Standard-Bibliothek ist mir schleierhaft. Die meisten StdLib Container sind bereits in neuer C++0x move Semantik verfügbar (gcc bzw. MS C++) und deutlich schneller. Den Vorteil hat man verschenkt.

    * Wenn Entwickler einmal glauben, das mit den Signals/Slots von Qt verstanden zu haben, wird es exzessiv benutzt ohne auf etwaige Seiteneffekte zu achten. Das Debuggen von sowas ist die pure Hölle. Und das Event-Dispatching wird schnell zum Performance Bottleneck.

    * Die Migration von Qt3 auf Qt4 ist _extrem_ aufwendig. Es gibt zwar Hilfen von Qt, aber die verringern die Handarbeit aber nur ein wenig.

    Daher mein Fazit: Qt nur ganz gezielt dort einsetzen, wo man es wirklich braucht und es großen Nutzen bringt (GUI, XML, Netzwerk/HTTP), dort wo speziell die Standard Bibliothek Lösungen anbietet immer die verwenden. Und auf keinen Fall den Code mit signal/slots zumüllen. Dann lieber ein Template basiertes Observer pattern verwenden.

    0
  • ?

    Qt container sind besser auf Standard-Use-Case orientiert, bspl suche in einem String:

    STL:

    std::string::const_iterator foundIter = std::find(text.begin(), text.end(), someSubstring);
if (foundIter != text.end()){Mache etwas...}

    Qt:

    if (text.contains(someSubstring)){Mache etwas...}

    Klar, die STL-Variante ist abstrakter, bildet aber den Standard-Use-Case nicht ab, wobei das an sich kein Problem wäre, innerhalb der String-Implementierung so eine Methode umzusetzen.

    Gerade das macht Qt so attraktiv, dass die Standardaufgabenstellungen vollständig gelöst sind. Egal, was man braucht, bietet Qt eine intuitive! Lösung.

    Der Missbrauch von Signal und Slots ist sicherlich ein Thema, weil die Leute nicht verstehen, dass diese für interne Objectkommunkation gedacht sind und nicht im globalen Kontext angewendet werden dürfen. Allerdings, es fehlt allgemeines Verständnis dafür, dass Interkommunikation zwischen den Objekten über ein streng definierten Mechanismus ablaufen soll, wie. z.B: Model/Observer Pattern.

    Die Portierung von Qt3 auf Qt4 bei dem Projekt der angesprochenen Größenordnung ist ein Aufwand von etwa einem Man/Monat, was durchaus akzeptabel ist, ausserdem ist das eher eine einmalige Geschichte (wollen wir jedenfalls so hoffen :))

    0
  • Administrator

    lepsai schrieb:

    Qt container sind besser auf Standard-Use-Case orientiert, bspl suche in einem String:

    STL:

    std::string::const_iterator foundIter = std::find(text.begin(), text.end(), someSubstring);
if (foundIter != text.end()){Mache etwas...}

    Qt:

    if (text.contains(someSubstring)){Mache etwas...}

    Klar, die STL-Variante ist abstrakter, bildet aber den Standard-Use-Case nicht ab, wobei das an sich kein Problem wäre, innerhalb der String-Implementierung so eine Methode umzusetzen.

    Naja, es gibt auch so eine Methode direkt in der std::string Version:
    std::string::find

    Und wir dürfen ja auch noch Boost verwenden:
    http://www.boost.org/doc/libs/1_44_0/doc/html/boost/algorithm/contains.html

    Sagen wir einfach, du kennst dich gut mit Qt aus, aber nicht so gut mit Boost und der Standardbibliothek, ok? 🙂
    Gibt leider viele, welche C++ zusammen mit Qt lernen und dabei nie richtig die Standardbibliothek gelernt haben, geschweige denn etwas wie Boost.

    Grüssli

    0
  • L

    http://www.cplusplus.com/reference/string/string/find/

    if(my_string.find(some_substr) != std::string::npos) { machWas(); }
    0
  • C

    Die Standardbibliothek bietet eigendlich alles was man brauch und wenn etwas nicht drin ist nimmt man Boost fertig.

    Gruß,
    Nico

    0
  • N

    gamebuntu schrieb:

    Die Standardbibliothek bietet eigendlich alles was man brauch und wenn etwas nicht drin ist nimmt man Boost fertig.

    Stimmt. Der Grossteil der restlichen C++-Bibliotheken ist ja auch nur entstanden, weil den Entwicklern langweilig war.

    0
  • A

    Es gibt ja auch noch andere Sachen die bei Qt hübsch gelöst sind (ausser XML, Threads, SQL, ... ). z.B. sind die QStrings und QFileInfo - und alles was damit zusammen hängt - enorm intuitiv.

    Dass QT jetzt Gefahr laufen sollte auszusterben sehe ich derzeit nicht - würde ohne weiteres auch grössere (Kunden)Projekte damit anlegen.

    Üblicherweise mische ich boost und Qt in Projekten: Kostet beides nix und ist stabil (auch in Konsolen-Tools). Magvielleicht auch daran lioegen dass die Doku für QT so gut ist (da sollten sich andere libs mal ein Scheibchen von abschneiden!).

    Das Argument der Trennung von GUI und Business-Logik ist so nicht ganz korrekt: Ja, architektonisch ist es sinnvoll GUI und den Rest voneinander sauber zu trennen. Das hat aber Wartungsgründe und NICHT den Grund dass man vielleicht irgend wann mal die GUI ersetzen will (von einem Projekt wo nur das passiert habe ich noch nie gehört). Also spricht nichts dagegen Qt-Klassen und Mechanismen (wenn sinnvoll) sonstwo einzusetzen solange die Trennung der GUI-Schicht bestehen bleibt.

    Gibt leider viele, welche C++ zusammen mit Qt lernen und dabei nie richtig die Standardbibliothek gelernt haben

    Das mag daran liegen, dass Qt mittlerweile Wrapper für viele Klassen aus der STL bietet die zusätzliche Funktionen und ein intuitiveres interface haben. Ob es jetzt so lobenswert/notwendig ist sich die STL hash anzuschauen wenn man schon perfekt mit QHash umgehen kann ist daher ansichtssache. Wenns um Performance geht muss man halt testen was besser ist.

    0
  • ?

    Ja, das stimmt, string war ein schlechtes Beispiel, aber wir können vector, list oder auch map nehmen. Mir ging es eher darum die STL/Boost Semantik in Frage zu stellen und mit der von Qt API zu vergleichen.

    Ich habe C++ gerade mit STL gelernt und nicht mit Qt und verwende sie sehr breit in meinem Code, muss aber sagen, dass außer Container-Iterator-Algorithm-Konzept, wenn man das so bezeichnen kann, ist der Rest auch nur ein mittelmäßiger Wrapper um die Standard C Bibilothek. Gerade STL ist in ihrem Umfang sehr klein, ich denke da sind wir uns einig...

    Dravere schrieb:

    lepsai schrieb:

    Qt container sind besser auf Standard-Use-Case orientiert, bspl suche in einem String:

    STL:

    std::string::const_iterator foundIter = std::find(text.begin(), text.end(), someSubstring);
if (foundIter != text.end()){Mache etwas...}

    Qt:

    if (text.contains(someSubstring)){Mache etwas...}

    Klar, die STL-Variante ist abstrakter, bildet aber den Standard-Use-Case nicht ab, wobei das an sich kein Problem wäre, innerhalb der String-Implementierung so eine Methode umzusetzen.

    Naja, es gibt auch so eine Methode direkt in der std::string Version:
    std::string::find

    Und wir dürfen ja auch noch Boost verwenden:
    http://www.boost.org/doc/libs/1_44_0/doc/html/boost/algorithm/contains.html

    Sagen wir einfach, du kennst dich gut mit Qt aus, aber nicht so gut mit Boost und der Standardbibliothek, ok? 🙂
    Gibt leider viele, welche C++ zusammen mit Qt lernen und dabei nie richtig die Standardbibliothek gelernt haben, geschweige denn etwas wie Boost.

    Grüssli

    0
  • A

    antialias schrieb:

    ... Das hat aber Wartungsgründe und NICHT den Grund dass man vielleicht irgend wann mal die GUI ersetzen will (von einem Projekt wo nur das passiert habe ich noch nie gehört).

    Das du dies noch nie gehört hast, liegt vermutlich auch daran, das häufig die Projekte so verzahnt sind, das man alles ändern muss (Ich kenne einige Projekte in dem das UI-Framework geändert werden sollte [u.a. weil das alte nicht mehr gewartet wurde, IDE-abhängig war...] - aber nicht konnte ohne das Projekt komplett neu aufzubauen).

    Grundsätzlich würde ich, auch aus meiner Vorerfahrung, grundsätzlich versuchen möglichst viele Programmteile von irgendwelchen Frameworks unabhängig zu gestalten, oder zumindest die Schnittstellen austauschbar zu halten.

    0
  • A

    lepsai schrieb:

    ...ist der Rest auch nur ein mittelmäßiger Wrapper um die Standard C Bibilothek...

    In der Regel gibt es keine oder kaum Abhängigkeiten zur C-Bibliothek, in sofern ist die Aussage einfach unsinnig.

    0
  • C

    da geb ich asc recht so viele Abhängigkeiten gibt es nicht und eine mittelmäßiger Wrappe der C Bibliothek kann man auch nicht sagen.

    0
Anmelden zum Antworten