Boost vs. QT

[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

[RHBaum]

An alle die, die meinen QT Abhaengigkeiten waeren kein Problem, oder kein Problem, wenn man alles hinter sauberen Qt-freien Schnittstellen verlinkt ...
Dann stellt euch mal vor, Ihr braucht in euerer GUI ein Supertolles Feature von nem Widget aus der qt4.7 und einer der Business Logik Programmierer hat, weil er sich nicht mit ner Sockectschnittstelle rumplagen wollte, er QDir etc cool fand ... sein Modul (dll) gegen die 4.5.X Qt gelinkt (Dynamisch, klar, iss ja standard bei der qt)

Schon mal viel Spass beim Konfliktloesen

Und Programme, wo ein Entwickler alles in Eigenkontrolle hat, da lohnt es nicht um Vor und Nachteile zu streiten (da gewinnen eh die Vorlieben), weil viele Themen (Abhangigkeiten, Wartungsfreundlichkeit, Compilerunabhaengigkeit, Plattformunabhaengigkeit) erst bei Projekten gewisser Groesse und Struktur nochmal an Brisanz stark zulegen.
Es ist ein Riesenunterschied, ob man Klassen / Bibliotheken schreibt, wo man weiss wo die zum Einsatz kommen, zu Projekten, wo man überhaupt NULL Plan hat, wer wie und wo spaeter Dein Zeugs verwenden wird.

Ciao ...

[Dravere]

RHBaum schrieb:

Dann stellt euch mal vor, Ihr braucht in euerer GUI ein Supertolles Feature von nem Widget aus der qt4.7 und einer der Business Logik Programmierer hat, weil er sich nicht mit ner Sockectschnittstelle rumplagen wollte, er QDir etc cool fand ... sein Modul (dll) gegen die 4.5.X Qt gelinkt (Dynamisch, klar, iss ja standard bei der qt)

Schon mal viel Spass beim Konfliktloesen

Kommt ganz darauf an, wie die Schnittstelle aussieht. Es gibt auch Schnittstellen über Programmgrenzen hinaus. Stichwort: RPC.

Grüssli

[antialias]

Damit ist die Businesslogik aber an QT gebunden, und ein Wechsel ist kaum möglich, ohne alles neu zu schreiben.

Das gilt für jede Lib - nicht nur für Qt. So lange die Nutzung der Qt-Klassen in der BL sauber von dem getrennt ist was die GUI liefert ist das kein Problem.

und habe schon mehrfach den Aufstieg und Fall eines Frameworkes wie QT erlebt.

Ich auch. Derzeit ist Qt ja nicht mehr Trolltech sondern Nokia und die haben sich mit Haut und Haaren dem Zeugs verschrieben - was sich in der stark erhöhten Entwicklungsgeschwindigkeit des Frameworks widerspiegelt. Ich würde Qt daher nur unwesentlich unsicherer ansehen als WPF (bzw. Silverlight) ...und mit als eine sicherere Alternative als micro-libs wie TinyXML oder no-name SQL libs zu verwenden). Derzeit hab ich einen Kunden der Silverlight als GUI haben will - das macht mir schon mehr Bauchschmerzen, da das noch ziemlich neu und hauptsächlich "clickie-buntie" ist.

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.

Keine Frage. Kennen sollte man die. Wenn man jedoch die Wahl hat Klasse QX oder Klasse X zu nehmen wobei QX = "X plus Features die in meinem Programm nützlich sind" ist ...dann würd ich halt Klasse QX nehmen.

Letztendlich gilt das Argument welches bei C# auf die Spitze getrieben wird: Der Programmierer soll sich nicht mehr mit low-level Zeugs rumärgern (string-inkompatibilitäten, etc ) und Zeit-effizient Code schreiben. Und dabei hilft Qt (und andere libs) enorm gegenüber einer Selbstbeschränkung auf die Standardbibliotheken.

[RHBaum]

Es gibt auch Schnittstellen über Programmgrenzen hinaus. Stichwort: RPC.

Ja schon, das wuerde das Problem mit der dll Abhaengigkeit loesen
Aber Du weisst scho, das IPC vs gemeinsammer speicherbereich mega lahm ist. Und IPC einfache Schnittstellen doch recht aufblaehen kann.

Also den Prozess wegen ner Schnittstelle auslagern ... naja nur wenn es ned anderes geht

Ciao ...

[asc]

antialias schrieb:

Derzeit hab ich einen Kunden der Silverlight als GUI haben will - das macht mir schon mehr Bauchschmerzen, da das noch ziemlich neu und hauptsächlich "clickie-buntie" ist.

So neu ist es nun auch nicht mehr, und "clickie-buntie" sehe ich auch nicht bei Silverlight, wenn man es nicht dazu macht (ich z.B. ziehe auch in WPF/Silverlight Oberflächen vor, die zwar optisch etwas ansprechend, nicht aber quitschebunt sind.

antialias schrieb:

Keine Frage. Kennen sollte man die. Wenn man jedoch die Wahl hat Klasse QX oder Klasse X zu nehmen wobei QX = "X plus Features die in meinem Programm nützlich sind" ist ...dann würd ich halt Klasse QX nehmen.

Solange du nur kurze "Lebensdauern" in einem Projekt erwartest, sehe ich da auch kein Problem. Wenn das Projekt aber auf sehr lange Zeit weiter entwickelt werden soll (und dies 10 und mehr Jahre umfassen kann), bin ich ein Befürworter
von möglichst wenig Ergänzungen in der Geschäftslogik, da diese ohnehin der Teil ist, der unabhängig von irgendwelchen Frameworks überdauern kann.

antialias schrieb:

Letztendlich gilt das Argument welches bei C# auf die Spitze getrieben wird: Der Programmierer soll sich nicht mehr mit low-level Zeugs rumärgern...

Wobei ich sagen muss, das ich in der Geschäftslogik nahezu nichts wirklich vermisse, das nicht auch in der C++ Standardbibliothek erfüllt werden kann. An Schnittstellen nach außen (UI, Datenbank etc.) sieht das wiederum gänzlich anders aus.

[RHBaum]

Der Programmierer soll sich nicht mehr mit low-level Zeugs rumärgern (string-inkompatibilitäten, etc ) und Zeit-effizient Code schreiben.

Ich geb Dir Recht, wenn damit Programmierung allgemein meinst!
Für c++ speziell geb ich Dir aber eher unrecht

Ich geb Dir recht, das sich z.b. GUI-Programmierer weniger mit "mit low-level Zeugs rumärgern", mal von 3D Rendering Geschichten abgesehen. Für die lohnt es sich einfach nicht, weil die meisten GUI's nie so schnell sein muessen ! (intelligentes cachen und Eventverhalten mal vorrausgesetzt).

Auf der anderen Seite, wenn wer nie "low level" programmiert, also Zeiger und referenzen nur unbewusst benutzt, und nie selber optimiert, sollte der ned auch ne andere Sprache nehmen ? In dem Bereich sind andere Sprachen wesentlich sauberer (von der syntax her) und in der Logik wesentlich intuitiver und damit leichter wartbarer ?

Die QT iss fuer mich z.b. deshalb kein ideales Produkt, weil sie einen absolut nichtidealen Bereich der Programmierung abdeckt. Sie ist irgendwo aufm halben Weg zwischen C++(systemnah) und Java(Abstract, aber sauber(er)).

Eine bessere Loesung als die GUI in c++ zu schreiben, nur weil der Unterbau aus diversen Gruenden in c++ sein muss, waer fuer mich, die GUI nicht in c++, und ueber eine kompatible Schnittstelle connecten (die auch inprozess sein kann).

In meinem Umfeld, in meiner Firma faellt in der Praxis eh folgendes gravierend auf:
Ich krieg viele GUI's von C++ Programmierern vorgesetzt (viele in qt, und ich find die aufn ersten Blick auch toll ). Der GUI selber sieht man aber auch an, das sie von einem Spezialisten gemacht ist, und nicht von jemanden der weiss wie der User arbeitet. Die verraet oft mehr ueber interne Implementationsdetails als ueber irgendwelche Anforderungen an so ein Programm.

Auf der anderen Seite haben wir aber auch Abteilungen (die nicht fuer uns zustaendig sind), die sich nur mit Human Interfaces beschaeftigen .... die wissen mit Farben zu arbeiten, wissen wie man Bedienfelder Anordnen muss um beim User gewisse Dinge zu erreichen, aber von denen kann keiner C++ wenn man einen erwischt, der Java kann, hat man scho glueck Aber irgendwelche Formulareditoren fuer HTML koennen die meisten ^^
Und siehts dann halt aus, Low Level Programmierer (mich eingeschlossen) sollt man nicht auf GUI's loslassen und die, die gut GUI's bauen koennten, haben meist kein Bock sich mit Zeigern Referenzen und Templates rumzuärgern

Ciao ...