STL vs. Qt
-
Vielen Dank für die schnellen Antworten.
Es ist mehr ein wissenschaftliches, als ein berufliches Projekt. Da ich an der Uni arbeite muss ich zum Glück niemandem gegenüber rechtfertigen, warum ich da was verwende
.Dass man sich mit Qt gegen Std-C++ stellt, hab ich so noch gar nicht gesehen. Aber jetzt wo du es sagst, fällt es schon auf. Die Qt-Alternativen drängen sich ja quasi auf. Daher wird es wohl auch einfacher seien dabei zu bleiben, denke ich.
Aber welche Anforderungen könnte es denn geben, dass das Program ohne Qt laufen sollte? Nur auf der Konsole oder nur mit einzelnen Klassen kann man doch auch mit Qt weiterarbeiten, oder?
-
Aber welche Anforderungen könnte es denn geben, dass das Program ohne Qt laufen sollte? Nur auf der Konsole oder nur mit einzelnen Klassen kann man doch auch mit Qt weiterarbeiten, oder?
Zu Qt gehört ja mehr, als nur die GUI-Library. Was ist mit dem MOC? Das ist ein sehr spezielles Qt-Tool, eine Blackbox sogar.
Wenn ein Projekt z.B. in 10 Jahren noch läuft muß es gepflegt werden. Was ist wenn sich z.B. die Lizenzbedingungen zu dem Zeitpunkt geändert haben, das sie "untragbar" für das Projekt sind? Man ist auf Qt-Technik angewiesen. Wenn man Std-C++ benutzt, hat man immer eine Chance andere Implementierungen von Std-Libs und Std-Compiler zu suchen, wo einem die Lizenz und Qualität besser gefällt.
Gut, das sind ja jetzt seeehr spezielle Szenarien. Und das trifft ja praktisch auf jede Lib und Technologie zu, die man benutzt. Qt ist da nicht alleine.
Deshalb meine Empfehlung, wenn dann gleich richtig und auf komplettes Qt setzen! Wenn jemand z.B. MFC benutzt, würde ich ihm auch erstmal raten komplette MFC zu nutzen. Denn mit der MFC hat man auch schon ein Signal gestellt: "Ich will nur für Windows entwickeln!". Völlig legitim, wenn man es bewusst so entschieden hat und die Zukunft mit berücksichtigt hat.
-
Alles klar! Nochmal danke für die Erklärung.
Diese lizenzrechtlichen Überlegungen habe ich mir auch schon gemacht. Im Moment möchte ich opensource entwickeln und hoffe, dass Andere aus der Community interesse haben und mithelfen.
Wie das mit Qt weiter geht, ist nach der Übernahme von Trolltech durch Nokia natürlich eine interessante Frage. Aber da halte ich mich erstmal an die großen, wie KDE, die keine Existenzängste zu plagen scheinen.
Bestens, ich hau jetzt mal in die Tasten.
-
Artchi schrieb:
Deshalb meine Empfehlung, wenn dann gleich richtig und auf komplettes Qt setzen! Wenn jemand z.B. MFC benutzt, würde ich ihm auch erstmal raten komplette MFC zu nutzen. Denn mit der MFC hat man auch schon ein Signal gestellt: "Ich will nur für Windows entwickeln!".
Nur aus der Verwendung einer proprietären UI-Bibliothek diese Absicht abzuleiten finde ich vorschnell. Die meisten meiner C++-Anwendungen verwenden ein User-Interface, das in C++Builder mit der VCL entwickelt wurde; unabhängig davon ist der funktionelle Teil meiner Anwendungen meist in portablem oder trivial portierbarem C++ geschrieben. Dadurch kann ich im Zweifelsfalle immer noch recht einfach das Frontend austauschen - und außerdem ergibt sich so die Trennung zwischen Model und View mehr oder weniger von selbst.
-
ich weiss ja nicht, was du genau vorhast, aber auch hinsichtlich der qt-metatypes ist es in qt-projekten oft eine gute wahl, die qt-alternativen fuer containerklassen usw. zu nutzen, weil man sie bspw. einfach mit QVariant oder sowas verwenden kann.
mfg,
julian
-
kaizimir schrieb:
Alles klar! Nochmal danke für die Erklärung.
Diese lizenzrechtlichen Überlegungen habe ich mir auch schon gemacht. Im Moment möchte ich opensource entwickeln und hoffe, dass Andere aus der Community interesse haben und mithelfen.
Wie das mit Qt weiter geht, ist nach der Übernahme von Trolltech durch Nokia natürlich eine interessante Frage. Aber da halte ich mich erstmal an die großen, wie KDE, die keine Existenzängste zu plagen scheinen.
Bestens, ich hau jetzt mal in die Tasten.
welche Ueberlegungen den so? Qt4 steht u.a. unter der LGPL, somit kannst du das mit allem verwenden und dein Programm kann deine eigene Lizenz haben. Finde nur schade das Trolltech/Nokia Qt Jambi (den Java Port von Qt) eingestellt haben. Ich hoffe es lebt als Community Projekt weiter, da ja LGPL.
Btw, C++ wuerde ich mir aber selbst mit Qt nicht antun. Nimm lieber einer der Ports: Python, Ruby, Java, C#, Php, usw.
-
DEvent schrieb:
Btw, C++ wuerde ich mir aber selbst mit Qt nicht antun. Nimm lieber einer der Ports: Python, Ruby, Java, C#, Php, usw.
Lieber PHP statt c++? Guter Witz!
-
Am Ende soll eine Analyse Software für elektrophysiologische Daten (waveform detection, clustering, correlations, usw.) stehen. Das Ziel kann ich vielleicht so in 2-3 Jahren erreichen...Bisher bin ich einfach nicht zufrieden mit den proprietären Tools, die es so auf dem Markt gibt. Ich glaube, ich kann das besser machen
.Die Datensätze können unter anderem sehr groß ausfallen, d.h. mehrere Millionen Datenpunkte meist in mehreren bis vielen Kanälen. Ich habe einen Prototypen in Matlab entwickelt, der allerdings abhängig von der Datenmenge sehr schlecht skaliert (wen's interessiert: http://www.mathworks.com/matlabcentral/fileexchange/15998).
Hinzu kommt, dass ein batch-mode vorgesehen ist, da dieser das Leben des Forschers erheblich erleichtert. Daher habe ich mich für C++ entschieden. Hier kann ich den Speicher effizient nutzen. Das ist auch der Grund, warum ich mich gegen Java entschieden habe, womit es aber sicherlich leichter von der Hand gegangen wäre.Und da kommts dann zur nächsten Frage STL vs. Qt:
Sind die Qt eigenen Datentypen genau so effizient einzusetzen, wie die der STL?audacia schrieb:
Die meisten meiner C++-Anwendungen verwenden ein User-Interface, das in C++Builder mit der VCL entwickelt wurde; unabhängig davon ist der funktionelle Teil meiner Anwendungen meist in portablem oder trivial portierbarem C++ geschrieben.
So etwas habe ich mir auch überlegt. Ein back- und ein frontend eben. Die Frage ist nur, wie aufwendig ist die Umsetzung, wenn man z.B. Qt für die GUI benutzt? Uns sorry, aber was heißt denn 'trivial portabel'? Und entnehme ich deiner Aussage richtig, dass du dann ebenhalt die STL für den funktionellen Teil verwendest, also für Vektoren z. B.?
-
kaizimir schrieb:
Uns sorry, aber was heißt denn 'trivial portabel'?
Mit "trivial portierbar" bezeichne ich mit geringem Aufwand beseitigbare Abhängigkeiten. Beispielsweise benutzte ich windows.h, weil darin BITMAPINFOHEADER und ähnliche Strukturen gespeichert sind - und wenn ich das Ganze nach Linux portieren wollte, beschränkte sich der Aufwand darauf, die Struktur aus dem Windows-Header herauszukopieren und ggf. geringfügig anzupassen.
kaizimir schrieb:
Und entnehme ich deiner Aussage richtig, dass du dann ebenhalt die STL für den funktionellen Teil verwendest, also für Vektoren z. B.?
Ja, natürlich. Die Delphi-RTL, die in C++Builder zur Verfügung steht, hat auch ihre eigenen Container, und manche Spezialfälle sind auch durchaus nützlicher als die STL-Alternativen (z.B. TStringList oder TObjectList), aber diese Container sind in Delphi geschrieben und können C++-spezifische Eigenheiten, z.B. die Wert- und Kopiersemantik von Klassen, nicht berücksichtigen, so daß es oftmals ohnehin sinnvoller ist, die STL-Container zu benutzen. Neben den Containern gibt es natürlich noch eine große Menge mehr oder weniger trivialer Plattform-Wrapper, beispielsweise für Dateioperationen; deren Benutzung verlagere ich aber nach Möglichkeit ohnehin ins UI-Frontend.
-
Artchi schrieb:
Aber welche Anforderungen könnte es denn geben, dass das Program ohne Qt laufen sollte? Nur auf der Konsole oder nur mit einzelnen Klassen kann man doch auch mit Qt weiterarbeiten, oder?
Zu Qt gehört ja mehr, als nur die GUI-Library. Was ist mit dem MOC? Das ist ein sehr spezielles Qt-Tool, eine Blackbox sogar.
MOC ist ein Code-Generator wie lex und yacc und was-auch-immer auch.
Im Gegensatz zu lex und yacc ist sogar die Eingangssprache C++.
Und natuerlich koenntest Du den Code auch von Hand schreiben
(auch wenn's sinnfrei waere)Wenn ein Projekt z.B. in 10 Jahren noch läuft muß es gepflegt werden. Was ist wenn sich z.B. die Lizenzbedingungen zu dem Zeitpunkt geändert haben, das sie "untragbar" für das Projekt sind? Man ist auf Qt-Technik angewiesen. Wenn man Std-C++ benutzt, hat man immer eine Chance andere Implementierungen von Std-Libs und Std-Compiler zu suchen, wo einem die Lizenz und Qualität besser gefällt.
Qt ist (unter anderen) LGPL, kann also zumindest in der von dem Projekt verwendeten Form bis auf alle Ewigkeiten unter der Lizenz verwendet werden.
Gut, das sind ja jetzt seeehr spezielle Szenarien. Und das trifft ja praktisch auf jede Lib und Technologie zu, die man benutzt. Qt ist da nicht alleine.
Deshalb meine Empfehlung, wenn dann gleich richtig und auf komplettes Qt setzen! Wenn jemand z.B. MFC benutzt, würde ich ihm auch erstmal raten komplette MFC zu nutzen. Denn mit der MFC hat man auch schon ein Signal gestellt: "Ich will nur für Windows entwickeln!". Völlig legitim, wenn man es bewusst so entschieden hat und die Zukunft mit berücksichtigt hat.
-
Vielen Dank für eure Beiträge. Sie haben mir sehr dabei geholfen zu entscheiden, wie ich das Problem angehen werde. Ich werde also versuchen, möglichst nahe am ANSI-Standard zu bleiben, sprich die STL einzusetzen wo es nur geht.
Da hierbei weitere und ganz konkrete Fragen aufgetaucht sind, habe ich einen weiteren Thread unter http://www.c-plusplus.net/forum/viewtopic-var-p-is-1750770.html#1750770 geöffnet.
Über eure rege Teilnahme freue ich mich.
greetz, Kai