Verwendung von Qt
-
Hallo Leute,
ich hab mal ne generelle Frage. Ich arbeite mich gerade in QT ein, und habe festgestellt, dass Qt nicht nur auschließlich ein GUI Framewok ist, sonst auch weit aus mehr bietet.
Wenn ich nun eine C++ anwendung schreibe, und das QT Framework habe ich ja bspw. die Wahl bszw. QString oder std:string zu verwenden, so dass ich quasi nur GUI bezogen strings mit QString handle, und generelle strings mit den std::string.
Das ganze geht ja nun weiter mit datenstrukturen etc.
Ich bin kein spezialist, aber ich hättte ja dann die wahl zwuischen datenstrukturen aus der stdlib, aus Qt und meinentwegen noch aus boost etc.
Wie entscheide ich nun am besten wann ich was verwende! Ich kann ja auch das ganze Program mit den qt Objekten coden, auch wenn diese zwangläufig nicht direkt mit der UI zu tun haben!
Würde mich um vorgehensweißen freuen:)
LG
-
Kommt drauf an, was du sonst so hast und wie GUI-lastig deine Anwendung ist oder sein wird. Mir würds wohl eher gefallen, die std lib zu verwenden. Versuch das so zumachen, wenn ich zu Hause was programmiere. Aber eigentlich hauptsächlich, damit ich das nicht komplett verlerne.
Wenn du ständig zwischen Standardbibliothek und Qt hin und her konvertieren müsstest, würde es wenig Sinn machen. Wenn du aber große, von der GUI völlig unabhängige Layer hast, würde es sich eher lohnen, hier den Standard zu benutzen. Dann könnte man Teile deines Projekts vielleicht in anderen Projekten wiederverwenden, bei denen man kein Qt einsetzen will. Und es würde natürlich leichter fallen, später auf eine andere GUI Bibliothek umzusteigen. Wobei das Argument sehr schwach ist, weil bei großen Projekten wird es immer sehr viel Aufwand sein.
Wir benutzen hauptsächlich Qt Klassen. Unser Programm ist schon 20 Jahre alt, damals war die Standardbibliothek und die Compiler noch nicht so weit. Dann hat die Firma irgendeine Bibliothek gekauft, die mittlerweile tot ist, und irgendwann durch Qt ersetzt. Das Ersetzen durch Qt war viel einfacher als das Ersetzen durch die Standardbibliothek. Wenn in der GUI früher XyzString benutzt wurde und in den grundlegenden Klassen, wars beim Austauschen der GUI Bibliothek natürlich viel einfacher, überall XyzString durch QString zu ersetzen. Man musste natürlich die Methoden usw. anpassen, aber man hat keinen zusätzlich Code gebraucht, um zwischen Standardbibliothek und GUI Bibliothek zu konvertieren.
-
NullBockException schrieb:
Wie entscheide ich nun am besten wann ich was verwende! Ich kann ja auch das ganze Program mit den qt Objekten coden, auch wenn diese zwangläufig nicht direkt mit der UI zu tun haben!
Richtig. Du kannst sogar auch in einem Programm, dass keinerlei GUI enthält, mit Qt arbeiten. Dann linkst Du, zum Beispiel, eben nur gegen QtCore aber nicht gegen QtGUI. Geht alles sehr gut
Die große Frage ist meiner Meinung nach vor allem die, ob der Code, den Du schreibst, auch außerhalb der "Qt Welt" wieder-benutzbar sein soll oder ob das für Dich das keine Anforderung darstellt.
Insgesamt würde ich persönlich eher zu den Qt-Klassen tendieren. Aber seit C++11 geht das aller meiste auch mit der Standard-Bibliothek. Vieles ist sogar fast identisch umgesetzt.
Vor C++11 sah das noch deutlich anders aus! Ich denke da z.B. an std::unordered_map, std::unique_pointer, std::thread, etc, was es alles erst seit C++11 gibt, aber schon viel länger in Qt
-
DeathCubeK schrieb:
NullBockException schrieb:
Wie entscheide ich nun am besten wann ich was verwende! Ich kann ja auch das ganze Program mit den qt Objekten coden, auch wenn diese zwangläufig nicht direkt mit der UI zu tun haben!
Richtig. Du kannst sogar auch in einem Programm, dass keinerlei GUI enthält, mit Qt arbeiten. Dann linkst Du, zum Beispiel, eben nur gegen QtCore aber nicht gegen QtGUI. Geht alles sehr gut
Die große Frage ist meiner Meinung nach vor allem die, ob der Code, den Du schreibst, auch außerhalb der "Qt Welt" wieder-benutzbar sein soll oder ob das für Dich das keine Anforderung darstellt.
Insgesamt würde ich persönlich eher zu den Qt-Klassen tendieren. Aber seit C++11 geht das aller meiste auch mit der Standard-Bibliothek. Vieles ist sogar fast identisch umgesetzt.
Vor C++11 sah das noch deutlich anders aus! Ich denke da z.B. an std::unordered_map, std::unique_pointer, std::thread, etc, was es alles erst seit C++11 gibt, aber schon viel länger in Qt
so sehe ich das auch!
wenn es keine "programmtechnischen gründe" gibt die std sachen zu nehmen dann nimm qt... (außer du willst wie schon gesagt den code nochmal ohne qt benutzen)
anosten bieten diese qt sachen eher vorteile wie einfacherer/schnellere portierbarkeit ... da diese qt sachen meines wissens nach eig sogar betriebssystem unabhänig sind... ( nicht alle aber die meisten... )
das sehe ich als kleinen vorteil... (falls ich eine portierung evt. mal anstrebe)
aber wenn ich mir 100% sicher bin das ich nicht portieren will , und es auch programmtechnisch egal ist ...
nutze icha uch manchmal std:: da du dann die qt libs nicht brauchst ...nebenbei haben qstring und std::string auch noch unterschiedliche stringfunktionen die manchmal auch bei mir die entscheidung beeinflussen welchen datentyp ich nutze...
also für mich ist as eher eine frage was will ich "wahrscheinlich" mal machen oder eben nicht... dann entscheide ich qt oder std...
hoff ich konnte helfen...
-
Hört sich nicht so an, als ob du dich auskennen würdest. Selbstverständlich ist die std Lib komplett portabel und betriebssystem unabhängig. Das "sogar" ist hier komplett fehl am Platz. Die Qt Klassen sind es natürlich auch, was die offiziell unterstützten Betriebssysteme angeht. Es ist ja jetzt keine große Kunst, einen betriebssystemunabhängigen Container in C++ zu schreiben.
-
Mechanics schrieb:
Hört sich nicht so an, als ob du dich auskennen würdest. Selbstverständlich ist die std Lib komplett portabel und betriebssystem unabhängig. Das "sogar" ist hier komplett fehl am Platz. Die Qt Klassen sind es natürlich auch, was die offiziell unterstützten Betriebssysteme angeht. Es ist ja jetzt keine große Kunst, einen betriebssystemunabhängigen Container in C++ zu schreiben.
Ja du hast nat. vollkommen recht eig ist portabilitat eher ein Argument für die std aber ich wollte eig damit sagen das man das von Problem zu Problem und der entsprechenden Lösungen unterscheiden sollte wie ich finde... Je nach dem was man wirklich braucht und was nicht...
Hab's etwas undeutlich bzw. Nicht treffend formuliert...Aber man kann auch mal googeln nach dem Unterschied... Qstrings sind sowie so nicht das selbe wie std strings ...
Wenn man weiß was der Unterschied ist weiß man auch wann man was nutzen sollte finde ich...Aber vielleicht mach ich's auch falsch ... Ich lerne immmer gern dazu...
-
Qt fährt seit einiger Zeit die kommerziellen Geschütze auf. Ich würde mir das gut überlegen, auf welches Pferd ich setze, erst recht wenn ich nur GUI brauche.
-
Zweifler schrieb:
Qt fährt seit einiger Zeit die kommerziellen Geschütze auf. Ich würde mir das gut überlegen, auf welches Pferd ich setze, erst recht wenn ich nur GUI brauche.
Quellen?
Ansonsten pure Behauptung ohne relevanz
-
Nach sehr schlechter Erfahrung mit mehreren "historisch gewachsenen" Anwendungen, die nur mit viel Mühe umstellbar sind, würde ich persönlich immer wenn eine lange Produktpflege geplant ist (Bei kurzlebigen Projekten eher nicht) eine saubere Schichtentrennung nutzen, und Bibliotheken jenseits von std/boost nur in solchen Schichten nutzen, die diese auch wirklich benötigen.
Ja, auch mit sauberer Schichtentrennung ist ein umschreiben auf andere Bibliotheken noch viel Aufwand, aber mit Sicherheit immer noch leichter als den Code als ganzes Umstellen zu müssen.
-
Wo gibt es denn bitte keine historisch gewachsene Software? Niemand kann irgendwas groß voraus und vor allem nicht für lange Zeit planen. Also planen kann man schon, aber genau wie im Leben wird dies mit ziemlich hoher Wahrscheinlichkeit nicht so wie geplant eintreffen. Sein Leben kann man ja auch nicht planen, obwohl es immer wieder Menschen versuchen. Das ist genauso unsinnig, wie für die Rente zu leben, die man vielleicht nie erreicht oder wo man gar keinen Bock mehr hat die verpassten Dinge nachzuholen. Man ist nur einmal 20, 30, 40, 50 usw. Mit der Rente fängt auch so langsam des rechts einordnen an, wo es dann zur Ausfahrt vom Leben geht.
Ein wenig planen ist ok, aber verplant euch nicht. Ihr lebt im Jetzt und Hier und danach sollte man auch handeln.
-
Verplant schrieb:
Wo gibt es denn bitte keine historisch gewachsene Software?
Es gibt viele Firmen, die nicht Produkt, sondern Projektentwicklung machen. Bei letzterer mag man auch mit solchen Anwendungen konfrontiert werden, muss sich aber nicht um deren Zukunft Gedanken machen.
Verplant schrieb:
Niemand kann irgendwas groß voraus und vor allem nicht für lange Zeit planen.
Wenn man Produktentwicklung betreibt (wie z.B. in meiner jetzigen und letzten Firma der Fall), kann man so etwas durchaus zu gewissen Grad planen. Es geht auch nicht darum jede Eventualität zu berücksichtigen, wohl aber sollte man die Software wartbar halten. Und da kommt durchaus eine Schichtentrennung entgegen, bei der man auch von vorne herein bestimmte Frameworks in einzelnen Schichten ausschließen kann - auch wenn dies eine Konvertierung an den Schnittstellen der Schichten bedeutet.
Leider wird häufig, gerade bei kleineren Firmen, nicht einmal eine rudimentäre Schichtentrennung gemacht, falls auch nur ein Framework ausfällt ist der Aufwand der Umstellung häufig enorm. Dabei ist eine solche Trennung nicht zwangsweise mehr Arbeit (vom Anfang einmal abgesehen), da man durch die Trennung den Code auch häufig verständlicher hält und eher mal weitere Funktionalitäten hinzufügen kann, die vorher nicht geplant waren - und selbst wenn man die Software gänzlich portieren muss, ist es leichter mit solchen Trennungen.
Und in beiden Firmen gab es einen solch harten Bruch (Wegfall bestimmter Frameworks etc.). Teilweise wurde einfach das Framework trotz eingestellter Wartung noch viele Jahre verwendet (Es läuft ja) und wenn es dann aber mit einem OS-Wechsel nicht mehr läuft kann dies von heute auf morgen das aus einer Firma bedeuten. Nichts planen ist halt auch keine Lösung, und umso mehr Abhängigkeiten man ungekapselt verwendet, bzw. nicht zumindest auf einzelne Schichten begrenzt, umso schlimmer können die Auswirkungen sein.
Als Entwickler kann mir das zwar eigentlich egal sein (Notfalls halt die Stelle wechseln), ich identifiziere mich aber zu einem gewissen Teil mit der Firma in der ich arbeite.
Verplant schrieb:
Ein wenig planen ist ok, aber verplant euch nicht. Ihr lebt im Jetzt und Hier und danach sollte man auch handeln.
Und wo verplant man sich wenn man Abhängigkeiten auf Codebereiche begrenzt?
-
OMG Schichtentrennung und das noch mit Frameworks die eh schon über-generalisiert sind. Wenn das nicht alles 1a dokumentiert ist, dann kann solchen eine übertriebene Generalisierung kräftig nach hinten losgehen. Das ist dann kein von Menschen mehr lesbarer Code, da kann man kaum noch den Programmfluss nachvollziehen was schon bei zu stark verdesignpatternder Software der Fall ist.
Man kann doch nicht mal planen ob eine Software-Bude die nächsten fünf Jahre überleben wird, oder wie viele Leute kommen und gehen in der Entwicklungsabteilung.
Es mag so sein, dass dies alles in deiner Firma klappt, für die Regel halte ich solche Firmen und somit solche große Planungsoptimismus nicht. Linux ist ein gutes Beispiel wie ohne viel Planung ein großartiges Stück Software über Jahre wachsen kann. Ich glaube dass ist sogar eines der größten und meist frequentiertesten Software-Projekte überhaupt.
Große Software braucht keine große Planung.
-
Verplanter schrieb:
OMG Schichtentrennung und das noch mit Frameworks die eh schon über-generalisiert sind. Wenn das nicht alles 1a dokumentiert ist, dann kann solchen eine übertriebene Generalisierung kräftig nach hinten losgehen. Das ist dann kein von Menschen mehr lesbarer Code, da kann man kaum noch den Programmfluss nachvollziehen was schon bei zu stark verdesignpatternder Software der Fall ist.
Was hat "verdesignpatternder" Software oder schlecht lesbarer Code mit Schichtentrennung zu tun? Hast du überhaupt schon einmal eine saubere Schichtentrennung erlebt?
Verplanter schrieb:
Man kann doch nicht mal planen ob eine Software-Bude die nächsten fünf Jahre überleben wird, oder wie viele Leute kommen und gehen in der Entwicklungsabteilung.
Ach, dann lieber "und nach mir die Sintflut"? Schöne Taktik. Ich habe erlebt was durch eine solche Herangehensweise passiert, gerade weil man meinte das Schichtentrennung so aufwändig wäre. Wenn man diese von vorne herein vorsieht, ist es aber nur initial etwas mehr Planungsaufwand, und richtig gemacht führt es jedenfalls nicht zu schlechter lesbaren Code.
-
asc schrieb:
Verplanter schrieb:
OMG Schichtentrennung und das noch mit Frameworks die eh schon über-generalisiert sind. Wenn das nicht alles 1a dokumentiert ist, dann kann solchen eine übertriebene Generalisierung kräftig nach hinten losgehen. Das ist dann kein von Menschen mehr lesbarer Code, da kann man kaum noch den Programmfluss nachvollziehen was schon bei zu stark verdesignpatternder Software der Fall ist.
Was hat "verdesignpatternder" Software oder schlecht lesbarer Code mit Schichtentrennung zu tun? Hast du überhaupt schon einmal eine saubere Schichtentrennung erlebt?
Don't feed the trolls
Schichtentrennung und/oder Modularisierung erzeugt - wenn sie richtig gemacht ist, d.h. die Interfaces der Schichten/Module klar, einfach und erweiterbar sind - meiner Erfahrung nach durch ihre bloße Anwesenheit schon lesbareren Code. Einfach weil Aufrufe in andere Schichten/Module sofort als solche zu erkennen sind. Da die Änderung von Modulinterfaces recht "teuer" ist, überlegt man sich 2x ob man diese für jede Kleinigkeit gleich ändern muss bzw investiert Zeit, die Interfaces gescheit zu machen - ein disziplinarischer Effekt stellt sich bei den Entwicklern ein.
Ansonsten bin ich auch ein Verfechter der Meinung, dass Bibliotheken in Schichten oder Modulen, in denen man sie nicht unbedingt braucht, nichts zu suchen haben.
Aber keine Regel ohne Ausnahme: Wenn eine Anwendung zu 90% aus GUI besteht, würde ich auch im traurigen Rest der Einfachheit halber z.B. auf Qt setzen. Sicherlich aber nicht im umgekehrten Fall.
-
Abgesehen davon, dass es wahrscheinlich ein Troll ist, kommt die Meinung, Schichtentrennung, Design Patterns usw. würden zu schlechter lesbarem Code führen fast daher, dass man keine Ahnung hat. Natürlich kann es schon mal passieren, dass man nicht sofort sieht, wie der Code funktioniert. Ja und? Nicht alles ist trivial, wenn die Software umfangreicher ist, dann muss man sich einigen Stellen reindenken. Die "Alternative", also falls man wirklich überall sofort sehen würde, was passiert, wäre, dass man auch an jeder Stelle das komplette Wissen über jedes Detail zigfach dupliziert und überhaupt nicht kapselt oder generalisiert. Aber ob man dann wirklich irgendwas besser sieht oder versteht wag ich sehr stark zu bezweifeln.
Wir hatten in der Firma auch so einen Bruch und haben ein Framework durch Qt ausgetauscht. War sehr viel Arbeit und hat noch Jahre gedauert, bis jedes Feature wieder funktioniert hat. Das war schon sehr hart. Da kann man sich durchaus schon mal im voraus überlegen, ob sich sowas lohnt.
Bei Qt ist die Gefahr aber denke ich geringer. Das andere war ein kommerzielles Framework, das kaum jemand verwendet hat (weiß gar nicht, wie das hieß), das auch nicht so gut war und irgendwann eingestampft wurde. Qt ist zumindest Open Source und viel bekannter und wird von vielen verwendet. Da ist die Wahrscheinlichkeit, dass es aufgegeben wird viel geringer.
-
Mechanics schrieb:
Bei Qt ist die Gefahr aber denke ich geringer. Das andere war ein kommerzielles Framework, das kaum jemand verwendet hat (weiß gar nicht, wie das hieß), das auch nicht so gut war und irgendwann eingestampft wurde. Qt ist zumindest Open Source und viel bekannter und wird von vielen verwendet. Da ist die Wahrscheinlichkeit, dass es aufgegeben wird viel geringer.
Ich würde jetzt gar nicht mal nur die Gefahr sehen, dass ein Framework eingestampft wird. Eine in den letzten Jahre vermehrt auftretende Anforderung dürfte z.B. sein, seine Programme mobil verfügbar zu machen.
Hat man große Teile seiner Codebasis plattform- und frameworkunabhängig gehalten, dürften einem solche Fälle viel leichter fallen.
-
Morle schrieb:
Ich würde jetzt gar nicht mal nur die Gefahr sehen, dass ein Framework eingestampft wird. Eine in den letzten Jahre vermehrt auftretende Anforderung dürfte z.B. sein, seine Programme mobil verfügbar zu machen.
Hat man große Teile seiner Codebasis plattform- und frameworkunabhängig gehalten, dürften einem solche Fälle viel leichter fallen.ganz im gegenteil ...
qt bietet mobile protierung ...
qt unterstützt z.b android ... wird dort auch zur entwicklung genutzt soweit ich weiß ...