Boost vs. QT

[RHBaum]

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 ...

[lepsai]

@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ß

[Dravere]

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

[Gast]

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.

[lepsai]

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 :))

[Dravere]

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

[l'abra d'or]

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

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

[CCodex]

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

Gruß,
Nico

[Nexus]

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.

[antialias]

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.

[lepsai]

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

[asc]

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.

[asc]

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.

[CCodex]

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.

[Nexus]

Warum sprecht ihr von Abhängigkeiten von der C-Standardbibliothek?

[asc]

Nexus schrieb:

Warum sprecht ihr von Abhängigkeiten von der C-Standardbibliothek?

Wegen folgendem:

lepsai schrieb:

...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...

Es gibt/gab zwar Implementation die in Teilen der C++ Bibliothek auf die C-Bibliothek aufsetzen, aber beileibe nur in kleinen Teilen.

[Nexus]

Ah, ok. Ich habe das im Sinne von Abhängigkeiten wie bei Qt verstanden, die man gut abwägen müsse, und mich deshalb etwas gefragt.

[antialias]

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 habs auch in MFC Projekten gesehen. Dort sind die GUI Klassen ja auch "theoretisch" getrennt vom Rest. Praktisch ist es halt auch so verzahnt wie du selbst schon erfahren musstest.

Dennoch spricht dies nicht völlig gegen die Verwendung von Qt (auch) im Businesslogik-Teil des Frameworks (abgesehen von Lizenzfragen). Dort QT zu benutzen heisst ja nicht automatisch die GUI-Schicht mit dem Rest zu verzahnen.

Klar - man hat halt dann Qt als lib permanent dabei (auch wenn man mal die GUI austauscht) - aber in grossen Frameworks hat man immer ein paar Libs mit drin.

z.B. gibt es ja Projekte die statt QtXML/SQL und threads gleich drei verschiedene andere Dinge einbinden. Ist das deiner Meinung nach sinnvoller als jetzt nur eine lib einzubinden die zufällig halt auch GUI kann?

Wenn Qt jetzt so eine Lib wäre wo sich alle Nase lang die API radikal ändert (besonders bei den nicht-GUI Klassen) oder es irgendwie in Gefahr wäre nicht mehr weiterentwickelt zu werden - dann hast du natürlich recht: Möglichst wenig Abhängigkeiten.
In diesem Fall kannst du ja immernoch die GUI gegen was neues/buntes austauschen.

Es macht für mich keinen Sinn eine Lib nicht zu verwenden die kostenlos, stabil und auf absehbare supported ist, nur um eine Abhängigkeit weniger zu haben. Vor allem wenn es eine Lib ist die so viele Vorteile bringt und so viele andere libs ersetzt.

Minimalismus in allen Ehren, aber man kanns auch zu weit treiben. Schliesslich könnte man dann auch argumentieren garkeine libs mehr zu verwenden und alles selbst zu machen.

[asc]

antialias schrieb:

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 habs auch in MFC Projekten gesehen. Dort sind die GUI Klassen ja auch "theoretisch" getrennt vom Rest. Praktisch ist es halt auch so verzahnt wie du selbst schon erfahren musstest.

Dennoch spricht dies nicht völlig gegen die Verwendung von Qt (auch) im Businesslogik-Teil des Frameworks (abgesehen von Lizenzfragen). Dort QT zu benutzen heisst ja nicht automatisch die GUI-Schicht mit dem Rest zu verzahnen.

Damit ist die Businesslogik aber an QT gebunden, und ein Wechsel ist kaum möglich, ohne alles neu zu schreiben. Mach es wie du meinst, ich halte die C++ Standardbibliothek und sogar boost für langlebiger als QT, und habe schon mehrfach den Aufstieg und Fall eines Frameworkes wie QT erlebt.

antialias schrieb:

z.B. gibt es ja Projekte die statt QtXML/SQL und threads gleich drei verschiedene andere Dinge einbinden. Ist das deiner Meinung nach sinnvoller als jetzt nur eine lib einzubinden die zufällig halt auch GUI kann?

Ich habe nichts gegen mehrere Bibliotheken, solange diese nur in begrenzten Teilen hinter Schnittstellen verborgen werden. Bei einer Schichtentrennung UI - BL - DAL, würde ich zumindest die BL möglichst unabhängig von QT & Co halten.

[Dravere]

lepsai schrieb:

Ja, das stimmt, string war ein schlechtes Beispiel, aber wir können vector, list oder auch map nehmen.

std::map ? Witzbold!

lepsai schrieb:

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...

STL ist wirklich klein im Vergleich zur Standardbibliothek. Redet ihr eigentlich nun von der STL oder von der Standardbibliothek? Also ich rede grundsätzlich von der Standardbibliothek von C++, was aber nicht die STL ist.

Die C++ Standardbibliothek auf Iteratoren und einfacher Wrapper um die C Bibliothek zu reduzieren, halte ich für völligen Unsinn. Schon nur das ganze Streamkonzept wird dabei völlig ausser acht gelassen, welches deutlich mächtiger ist als die I/O Möglichkeiten von C. Und es gibt noch sehr viel mehr in der Standardbibliothek. Die Aussage erinnert mich doch stark an jemanden, der gerade mal ein Einsteigerbuch zu C++ durch hat und sich sonst noch nicht näher mit der C++ Standardbibliothek beschäftigt hat.

antialias schrieb:

Ob es jetzt so lobenswert/notwendig ist sich die STL hash anzuschauen wenn man schon perfekt mit QHash umgehen kann ist daher ansichtssache.

Problem ist eher, dass zu C++ auch die Standardbibliothek gehört. Wenn sich jemand bei mir als C++ Programmierer bewerben würde, würde ich davon ausgehen, dass er die Standardbibliothek kennt. Man verwendet nicht überall einfach auch Qt.
Zudem sehe ich ein starkes Problem darin, wenn sich jemand vollständig an Qt bindet. Man macht sich abhängig von einer einzigen Firma. Qt ist kein Standard. Es steht Trolltech frei, irgendwann einmal ihre Lizenzpolitik wieder zu ändern.

antialias schrieb:

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.

lepsai schrieb:

Mir ging es eher darum die STL/Boost Semantik in Frage zu stellen und mit der von Qt API zu vergleichen.

Da wiederhole ich mich gerne nochmals, sowas ist eine subjektive Meinung. Ich finde Qt nicht intuitiver. Im Gegenteil, die Klassen sind nach altmodischem Stil oft völlig überladen. Kein Wunder, denn es wird ja vollständig (oder fast?) auf freie Funktionen verzichtet. Es wird auch viel zu viel Wert auf Vererbung gelegt und zu wenig andere Design-Ansätze in betracht gezogen. Qt erinnert stark an andere Bibliotheken, vor allem auch aus anderen Sprachen. Würde mich nicht erstaunen, wenn gewisse Leute es vor allem deswegen als intuitiv sehen, weil es anderen Bibliotheken aus anderen Sprachen ähnelt. Also einfach nur der Gewohnheit entsprechen. Die Gewohnheit muss aber nicht intuitiv sein.

Aber eben, schlussendlich läuft es auf eine subjektive Meinung hinaus.

Zur Diskussion mit Qt in der Business Logik:
Solange kein Qt in der Schnittstelle zwischen Business Logik und GUI auftaucht, sehe ich da kein Problem. Qt hat in der Schnittstelle allerdings definitiv nichts verloren. Und Wartbarkeit heisst im übrigen auch, dass man Komponenten leicht austauschen kann.

Grüssli