Falls es den Thread schon gibt, tut es mir Leid, ich habe via Google naemlich gesucht, aber nicht gefunden.
Was mich heute interessiert, ist, ob Boost oder QT unterschiedlich sind. Ich habe gerade Boost kennen gelernt und bin begeistert und lese mir jeden Tag einiges davon durch.
Jetzt meinte ein Kollege, QT sei vieeeeeel besser, da einfacher zu bedienen. Er hat mir dann ein paar SQL-Klassen und Socketklassen gezeigt und meinte, wie einfach das sei... habe das an den Beispielen zwar nicht gesehen, weil die mit UI vermischt waren, aber gut. Und auch wenn es einfacher ist, ist das fuer mich selten ein Argument, weil einfache Bedienung immer irgendwo Nachteile hat :P Jedenfalls oft, aber ich bin kein Experte.
QT bietet natuerlich plattformunabhaengige GUIs an, was sehr schoen ist.
Nach kurzer Recherche im Internet habe ich nur wenig gefunden, allerdings u.a. einige, die QT und Boost gemischt einsetzen, was wohl heisst, dass QT fuer Oberflaechen und Boost fuer die Logik verwendet wird.
Wieso wuerden diese Leute nicht nur QT benutzen? Es scheint ja noch etwas umfangreicher zu sein und XML-Parser zu haben etc., aber auch da bin ich nicht ganz sicher.
Da ich davon ausgehe, dass es hier einige gute Programmierer gibt und QT wegen der "einfachen Bedienung" sicher auch von vielen benutzt wird, die C++ Templates nicht so verstehen (das ist jetzt eine sehr provokative Unterstellung und korrigiert mich, wenn ich falsch liege, aber das kam bei den wenigen Googlediskussionen imo etwas raus), wende ich mich lieber vertrauensvoll an dieses Forum hier.
Also, was denkt ihr dazu?
Vielen Dank im Voraus!
Zuletzt bearbeitet von Eisflamme am 02:31:56 09.09.2010, insgesamt 1-mal bearbeitet
Ich würde Qt nur dann einsetzen, wenn ich auch die Gui brauch, und diese nur mit Qt bereitstellen will. Wenn für die Gui kein Framework festgelegt werden soll, würde ich auch kein Qt einsetzen. Brauch ich überhaupt keine Gui, dann sowieso alles ohne Qt.
Qt ist schön und ich mag es sehr, nur ist es für eine reine Konsolenanwendung (oder einen Daemon) viel zu viel zusätzlicher Ballast. Neben dem dass Qt in den meisten Distributionen auch gleich X installiert und das noch mehr unnötigen Mist (aus Sicht des Rechner-Admins) mit anzieht, ist die Lizenz restriktiver als bei boost.
Was mich heute interessiert, ist, ob Boost oder QT unterschiedlich sind.
QT und Boost haben nur eine Teilüberschneidung. QT ist ein Framework was versucht alles abzubilden (von DB-Zugriffen bis Oberflächenprogrammierung), Boost ist eine Bibliothekssammlung die eher auf der Denkweise der STL, und bei weiten nicht versucht alles abzubilden.
Ich ziehe STL und Boost für die Programmlogik vor, und umfangreichere Frameworks für die Reine Datenbank- und UI-Schicht.
Gerade wenn ein Projekt Jahre oder Jahrzehnte gepflegt wird (wie die letzten beiden an denen ich gearbeitet habe), ist es zumindest in meinen Augen sinnvoll, sich nicht zu viele Abhängigkeiten zu riesigen Frameworks zu holen (Ich habe schon mehrere Frameworks sterben sehen, und Firmen die mit aller Gewalt an diesen, schon seit vielen Jahren nicht mehr unterstützten Frameworks hangen, und mit jeder OS-Generation mehr Ärger bekommen haben).
Die STL oder Boost halte ich für wesentlich "stabiler" als z.B. QT, MFC, VCL usw. Zudem kann es immer mal passieren das ein "besseres" Framework kommt, das z.B. für die UI besser geeignet ist. Bei schnelllebigen Projekten ist dies kein Problem, bei langlebigen würde ich zumindest eine grundsätzliche Austauschbarkeit als wichtig erachten.
Etwas ganz anderes habe ich zudem in Projekten erlebt die sich auf ein Framework eingeschossen haben: Häufig wird die Programmlogik früher oder später in die GUI gelagert (Das ist zwar kein Zwang, aber eine Tendenz die ich aus Projekten fest gestellt habe).
_________________ in theory there's no difference between theory and practice. in practice there is. (yogi berra)
In der Theorie gibt es kein Unterschied zwischen Theorie und Praxis. In der Praxis sehr wohl.
Ich nutze Qt nur für die Sachen, die mir die Standard-Bibliothek bzw. boost nicht liefern. Ausnahme: Netzwerk, da Nutze ich ebenfalls Qt.
Der vielbeschworene Vorteil von Qt - nämliche der schnelle Einstieg und das einfache Anwenden - sind m.E. auch dessen Fluch. Wie der Threadstarter oben bereits angedeutet hat: Da wird dann munter GUI und Netzwerkcode gemischt und, was ich am schlimmsten finde, sobald die Leute das mit signal und slot verstanden haben, fliegen unzählige Signale durchs System, weil der Mechnismus auch für nicht Qt Logik verwendet wird.
Dann ist das Framework mit dem Rest des Programms "verklebt" was die Wartung unnötig erschwert.
Okay, aber die Argumente der Verschmelzung von UI und Programmlogik gelten ja für den aufmerksamen Programmierer nicht, oder? Ich mein, das kann passieren, aber kann man das als ernsthaftes Argument durchgehen lassen? Schwierig, würde ich sagen.
Mit der Langlebigkeit der Projekte stimmt das mit Boost vs QT womöglich schon. Aber ich glaube, so etwas entwickle ich zur Zeit nicht.
Na ja und sonst so? Wegen der Aufgeblähtheit wurde mir entgegnet, dass durch die Modularisierung von QT das eigentlich kein Argument sei, da sowieso immer nur das eingebunden wird, was verwendet wird. Ich bin ehrlich gesagt nicht sicher, wie viel davon eingebunden wird oder nicht, ob es, um als Windowsnutzer zu sprechen, für Teile gesonderte libs gibt und dass die Header halt auch wie üblich eben nur bestimmte Funktionalitäten einbinden.
Und dann verstehe ich nicht: Wenn QT mehr als Boost hat und man beides nutzt, wieso dann nicht nur QT? Ebenfalls Austauschbarkeitsmöglichkeit für den UI-Teil erhalten?
Austauschbarkeit für den GUI-Part ist ein Argument. Das andere mit der Abhängigkeit zu X hast du ganz unterschlagen :P boost selbst braucht eigentlich nur die STL (in vielen Bereichen nicht mal das) und einen C++-Compiler. Plattformspezifische Sachen für asio und threads sollten sowieso vorhanden sein.
Um was für Teile geht es dir denn jetzt speziell? SQL? wirklich schwerer ist das manuelle Handhaben nicht. Einziger Vorteil: ich kann den Datenbanktreiber on-the-fly ändern. Aber ehrlich: wann machst du das?
Entweder soll die DB eine einfache Variante sein, Daten deiner Desktop-Applikation zu speichern -> sqlite.
Oder du brauchst eine komplexe DB, Zugriffe sind Zeitkritisch -> MySQL/PostgreSQL/...
Du möchtest keinen SQL-Server laufen lassen? sqlite, mysql-embedded, User-eigener mysqld.
usw.
Es ist also nur minimal bequemer mit QtSQL, dafür bindest du dich absolut an QT, denn QtSQL arbeitet mit QVariant! Dadurch werden die SQL-Typen in Qt-Typen "gecastet", was eine Verwendung in einer anderen Umgebung als Qt erschwert und ein ganzes Projekt neu geschrieben werden darf, sollte Qt wegfallen.
Dass Qt modular ist ist ja schön, aber SO modular ist es auch wieder nicht. libQtCore enthält schon so viel, was man nicht unbedingt braucht - Threads, Regexp, usw. Mit boost kannst du das wenn nötig mitlinken, ansonsten lass es weg. libQtCore hat hier 2,6MB, libQtNetwork hat 1,2MB.
Macht für bissl Core-Funktionalität gleich 3,8MB! Wenn eh schon Qt läuft ist es egal...
Verwende std::tr1 (oder Funktionen wie threads, die mit dem nächsten Standard kommen, aber jetzt schon von den meisten std-libs/compilern unterstützt werden) und du solltest gar kein Argument mehr für Qt haben.
Wenn du weißt, dass du nur Qt für die Gui einsetzen wirst, dann ist es natürlich absolut kein Problem, für alles andere auch gleich Qt zu nehmen - wobei ich auch hier mittlerweile genau überleg ob ich das wirklich will
Okay, das sind doch Mal eine Hand voll Argumente. Ich dachte mir doch gleich, dass ich wieder nur Halbwissen-Geschwätz präsentiert bekomme, denn richtige Argumente von meinem Kollegen außer "das ist viel leichter" gab es nicht... aber hätte ich auch nicht erwartet.
Von X habe ich keine Ahnung, das wird dann unter Linux relevant sein, oder? Keine Ahnung, ob ich da X installieren würde oder nicht.
Ich glaube, dann finde ich Boost + QT tatsächlich doch ganz cool. Vielleicht weiß ich zum Teil ja nicht Mal, ob ich eine Oberfläche benutzen möchte... oder ich will die halt nachher tatsächlich Mal ersetzen. Wenn SQL so eine Abhängigkeit zu QT schafft, würde ich das wohl tatsächlich nicht benutzen.
Nagut, danke! Weitere Punkte interessieren mich natürlich nach wie vor!
Wenn SQL so eine Abhängigkeit zu QT schafft, würde ich das wohl tatsächlich nicht benutzen.
Grundsätzlich habe ich gegen eine QT-Abhängigkeit nichts, solange sie nur bestimmte Schichten der Anwendung betrifft (Wenn die Schnittstelle zur Datenschicht kein QT enthält, es aber in dessen Implementierung enthalten ist, kann man es dennoch leicht austauschen).
_________________ in theory there's no difference between theory and practice. in practice there is. (yogi berra)
In der Theorie gibt es kein Unterschied zwischen Theorie und Praxis. In der Praxis sehr wohl.
Nach kurzer Recherche im Internet habe ich nur wenig gefunden, allerdings u.a. einige, die QT und Boost gemischt einsetzen, was wohl heisst, dass QT fuer Oberflaechen und Boost fuer die Logik verwendet wird.
Wieso wuerden diese Leute nicht nur QT benutzen?
Weil diese Leute, wenn ihre Anwendung sowas wie eine Architektur besitzt, GUI und Programmlogik voneinander getrennt in verschiedenen Modulen/Schichten implementieren und jede Schicht die Frameworks/Bibliotheken benutzt, die für die jeweilige Aufgabe (nach Meinung des Entwicklers/Designers) am Besten geeignet ist. Also beispielsweise QT für die GUI-Schicht, einzelne boost-Bibliotheken für die Anwendungslogik usw.
Dass Qt modular ist ist ja schön, aber SO modular ist es auch wieder nicht. libQtCore enthält schon so viel, was man nicht unbedingt braucht - Threads, Regexp, usw. Mit boost kannst du das wenn nötig mitlinken, ansonsten lass es weg. libQtCore hat hier 2,6MB, libQtNetwork hat 1,2MB.
Macht für bissl Core-Funktionalität gleich 3,8MB! Wenn eh schon Qt läuft ist es egal...
Sag mal das ist nicht dein ernst du Hoschi? Im Zeitalter von mehreren GB RAM ist es so etwas von Schnuppe ob eine einzelne Anwendung 1MB oder 10MB schluckt. Auf das Rausgerede bin ich jetzt mal gespannt aber ich denke ich werde wieder laut lachen.
Sag mal das ist nicht dein ernst du Hoschi? Im Zeitalter von mehreren GB RAM ist es so etwas von Schnuppe ob eine einzelne Anwendung 1MB oder 10MB schluckt. Auf das Rausgerede bin ich jetzt mal gespannt aber ich denke ich werde wieder laut lachen.
Freut mich, dass du bei meinen miesen Kommentaren wenigstens deinen Humor behalten hast.
Es mag sein, dass DU mehrere GB hast, ich hab auf meinem Desktop nur eines, das mir leider auch immer viel zu schnell ausgeht... Du ignorierst desweiteren Geräte, die nur über beschränkte Ressourcen verfügen, bei denen macht das sicher einiges aus.
Und möglichst ressourcenschonend programmieren sollte man unbedingt! Oder legst du auch per Default immer Arrays mit zigtausend Elementen an, obwohl du in 99,9% der Fälle nur 0,1% davon brauchst, in den restlichen 0,1% evtl. 2%? "Ist ja egal, hab ja genügend Speicher". Mannmannmann, du hoschi...
Außerdem, das war nur ein Punkt den ich erwähnt habe, der ins Gewicht fallen kann, also das nächste Mal den Post nochmal lesen und in angemessenem Ton dein Kontra geben.
Nach kurzer Recherche im Internet habe ich nur wenig gefunden, allerdings u.a. einige, die QT und Boost gemischt einsetzen, was wohl heisst, dass QT fuer Oberflaechen und Boost fuer die Logik verwendet wird.
Wieso wuerden diese Leute nicht nur QT benutzen?
Weil diese Leute, wenn ihre Anwendung sowas wie eine Architektur besitzt, GUI und Programmlogik voneinander getrennt in verschiedenen Modulen/Schichten implementieren und jede Schicht die Frameworks/Bibliotheken benutzt, die für die jeweilige Aufgabe (nach Meinung des Entwicklers/Designers) am Besten geeignet ist. Also beispielsweise QT für die GUI-Schicht, einzelne boost-Bibliotheken für die Anwendungslogik usw.
Klar, ich würde das auch voneinander trennen, MVC z.B. und so.
Mir geht es jetzt aber mehr darum, wieso für die Datenschicht extra boost und nicht QT verwendet worden ist, hätte man mit QT doch nur eine Bibliothek/ein Framework einbinden müssen.
Sag mal das ist nicht dein ernst du Hoschi? Im Zeitalter von mehreren GB RAM ist es so etwas von Schnuppe ob eine einzelne Anwendung 1MB oder 10MB schluckt. Auf das Rausgerede bin ich jetzt mal gespannt aber ich denke ich werde wieder laut lachen.
Auweia, auf welcher Schule bekommt man denn sowas eingetrichtert?
Klar, nach der Logik kannst du arbeiten. Aber wie heißt es so schön: auch Kleinvieh macht Mist, und wenn du dein "Konzept" nur lange und konsequent genug verfolgst, hast du irgend wann eine Applikation, die für minimalen Funktionsumfang so viel Ressourcen verbraucht, dass die Anwender dann laut über dich lachen.
Mal abgesehen davon solltest du mit dieser Einstellung nie versuchen, Geld mit Software in den Bereichen
- Prozessteuerung
- Automation
- Visualisierung
- hardwarenahe Programmierung
- Embedded Systems
- Treiberentwicklung
- Echtzeitapplikationen
zu verdienen (ich habe bestimmt noch 'zig andere vergessen, das sind die, die mir auf Anhieb einfallen).
Wir haben nichts zu sagen, deshlab packen wir die Aggro-Keule aus
Da du entweder wirklich keinen Peil hast, oder einfach grad auf irgendwen Sauer bist, ein kleines Beispiel aus der Praxis:
Erinnere dich an das Windows Vista-Desaster, wegen dem MS das ungeliebte XP weiter hat pflegen müssen, weil sich irgend welche Entscheider nicht um Ressourcen geschert haben, und deshalb Vista auf Netbooks unbenutzbar war. Das hat am Ende dazu geführt, dass XP-Support nochmal um einige Monate/Jahre hat verlängert werden müssen, der natürlich auch kostet (Code-Wartung, Kundensupport, ...), und garantiert ettliche Millionen $ geschluckt hat. Da hat man wohl auch gedacht "wir haben ja zig GB Arbeitsspeicher ung $MEGA-Gigahertz-Prozossoren, da muss man nicht so aufpassen was man treibt".
Wir haben nichts zu sagen, deshlab packen wir die Aggro-Keule aus
Da du entweder wirklich keinen Peil hast, oder einfach grad auf irgendwen Sauer bist, ein kleines Beispiel aus der Praxis:
Erinnere dich an das Windows Vista-Desaster, wegen dem MS das ungeliebte XP weiter hat pflegen müssen, weil sich irgend welche Entscheider nicht um Ressourcen geschert haben, und deshalb Vista auf Netbooks unbenutzbar war. Das hat am Ende dazu geführt, dass XP-Support nochmal um einige Monate/Jahre hat verlängert werden müssen, der natürlich auch kostet (Code-Wartung, Kundensupport, ...), und garantiert ettliche Millionen $ geschluckt hat. Da hat man wohl auch gedacht "wir haben ja zig GB Arbeitsspeicher ung $MEGA-Gigahertz-Prozossoren, da muss man nicht so aufpassen was man treibt".
Mal im Ernst, wie soll man bei so einer Gülle ruhig bleiben? Ich schreibe etwas von einzelnen StandAloneAnwendungen und der hier kann wieder nicht lesen oder verstehen und fängt wieder mit der ganzen Grütze an die ich extra ausgeschlossen hatte. Mann mit dem ganz tollen WauWau Namen: Erst lesen dann schreiben, haste bestimmt schon einmal gehört.
@LochImEimer:
Ich verstehe nicht warum du dich so streubst. Es war hier nie die Rede von Desktopanwendungen, es ging darum immer gleich auf Qt zu setzen - oder eben nicht.
Man sollte sich in jedem Fall vorher Gedanken darüber machen, was die Zielplattformen sind. Ist von vornherein nicht auszuschließen, dass das Programm auch auf schwachen embedded-Systemen laufen soll, dann verzichte ich in den interessanten Bereichen von vornherein auf Qt und schau mich nach Alternativen um. Wenn boost eine schöne Alternative bietet - toll, nehm ich das!
Das schöne an boost ist ja eben, dass man explizit ein Feature anziehen kann, das man braucht, ohne gleich einen ganzen zusätzlichen Rattenschwanz (wie bei Qt) zu bekommen. Brauch ich einen XML-Parser, greif ich ja auch nicht blind zu QtXML, sondern nehm (z.B.) rapidxml oder pugixml (letzteres kann XPath, was Qt jedenfalls in 4.6.3 nicht kann). Pumuckl hat es schon gesagt: Jede Schicht das Minimum an Abhängigkeiten, die nötig sind.
Das Vista-Beispiel hab ich nicht wg. meinen fehlenden Lesefähigkeiten gebracht, sondern 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?".
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.
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, ...
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.
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...
Es ist klar, dass Qt bei weitem der Boost Bibliothek überlegen ist
Es ist nicht klar sondern deine Meinung
Zitat:
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).
Zitat:
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.
Zitat:
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
Zitat:
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.
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 ...
Zuletzt bearbeitet von RHBaum am 14:26:10 14.09.2010, insgesamt 3-mal bearbeitet
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.
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.
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.
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 )
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
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.
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.
Zitat:
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.
Zuletzt bearbeitet von antialias am 09:12:13 16.09.2010, insgesamt 2-mal bearbeitet
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:
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
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.
... 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.
_________________ in theory there's no difference between theory and practice. in practice there is. (yogi berra)
In der Theorie gibt es kein Unterschied zwischen Theorie und Praxis. In der Praxis sehr wohl.
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.
_________________ in theory there's no difference between theory and practice. in practice there is. (yogi berra)
In der Theorie gibt es kein Unterschied zwischen Theorie und Praxis. In der Praxis sehr wohl.
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.
Zuletzt bearbeitet von antialias am 16:34:39 16.09.2010, insgesamt 3-mal bearbeitet
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.
_________________ in theory there's no difference between theory and practice. in practice there is. (yogi berra)
In der Theorie gibt es kein Unterschied zwischen Theorie und Praxis. In der Praxis sehr wohl.
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.
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 ...
Zuletzt bearbeitet von RHBaum am 14:27:02 17.09.2010, insgesamt 1-mal bearbeitet
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.
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.
Zitat:
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.
Zitat:
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.
Zuletzt bearbeitet von antialias am 14:56:47 17.09.2010, insgesamt 2-mal bearbeitet
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 :-)
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.
_________________ in theory there's no difference between theory and practice. in practice there is. (yogi berra)
In der Theorie gibt es kein Unterschied zwischen Theorie und Praxis. In der Praxis sehr wohl.
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 ...
Zuletzt bearbeitet von RHBaum am 15:33:03 17.09.2010, insgesamt 2-mal bearbeitet
Der Programmierer soll sich nicht mehr mit low-level Zeugs rumärgern (string-inkompatibilitäten, etc ) und Zeit-effizient Code schreiben.
Für c++ speziell geb ich Dir aber eher unrecht :-)
Definiere bitte mal Low-Level.
Für mich ist C++ keine Low-Level Sprache, sondern eine Hochsprache die Low-Level zulässt. Selbst die C++ Standardbibliothek ist für mich nicht Low-Level (wenn auch bewusst nicht so ausgebaut wie in anderen Sprachen).
Für mich gehören beispielsweise Zeiger zwar nicht zwangsweise gemieden, aber sind dennoch an vielen Stellen unnötig (und das Weglassen selbiger bedeutet nicht zwangsläufig merkliche Auswirkungen auf die Performance) und fehlerträchtig. Zeiger sollte man wie jedes Sprachmittel hinterfragen. Wo man sie benötigt soll man sie verwenden, aber wenn sie nicht nötig sind (und es gibt viele Bereiche wo C++ Alternativen anbietet) sollte man sie aber auch weglassen.
Jedes größere Projekt sollte vor allem pflegbar sein. Und selbst das Projekt an dem ich gerade arbeite sehe ich trotz nur 185.000 Codezeilen schon als solches an (auch wenn ich schon in C++ Projekten mit mehreren Millionen Codezeilen gearbeitet habe).
_________________ in theory there's no difference between theory and practice. in practice there is. (yogi berra)
In der Theorie gibt es kein Unterschied zwischen Theorie und Praxis. In der Praxis sehr wohl.
So neu ist es nun auch nicht mehr, und "clickie-buntie" sehe ich auch nicht bei Silverlight,
gemeit war, dass nicht sicher ist wie lange das überlebt, oder ob das Framework (zumindest der Subteil der Silverlight repräsentiert) irgendwann eingestampft wird. Auch Microsoft hat schon ganze Frameworks (und auch Programmiersprachen) sterben lassen. Und dann sitzt man halt mehr aufm trockenen als wenn man QT benutzt - was wenigstens open source ist und dann sicher in einer breiten community einige Zeit weiter gepflegt wird (siehe die anderen open source GUI frameworks da draussen).
Also ist Silverlight in meinen Augen nicht intrinsisch 'zukunftssicherer' als Qt. Aber welche lib ist das schon auf 10-15 Jahre?
Das Bauchgrimmen mit Silverlight kommt hauptsächlich von der Forderung, dass die Software auch aufm Mac laufen soll. Da wär mir Qt schon lieber gewesen. So bin ich auf das Überleben von Silverlight UND Mono angewiesen.
Zitat:
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.
Idealerweise hast du recht. Kunden wollen aber auch in endlicher Zeit an den Markt - ansonsten stirbt das Projekt aus Finanzgründen und die Programmierer werden arbeitslos. Muss man halt immer sehen wie lange der Atem des Kunden ist. Wenn ich durch den Einsatz einer komfortablen lib viel Zeit sparen kann ist das ein starkes Argument.
Finanziell ist es besser mit weniger Kosten an den Markt zu kommen und dafür dann irgendwann teuer die Software umzubauen als sie einmal (nicht ganz so teuer) zu bauen aber vor der Markteinführung Konkurs zu gehen (bzw. vom Konkurrenten überholt zu werden und erst garnicht aufm Markt bestehen zu können)
Zitat:
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.
Ein einem 0-8-15 Line-of-Business Projekt mag das sicher richtig sein. Ist meiner Erfahrung nach wirklich stark abhängig von was für Anwendungen wir hier reden.
Zitat:
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 :-)
Auch das ist der Idealfall (idealerweise solte man auch Interface Designer, Farbpsychologen und was weiss ich nicht alles noch drauf loslassen). Die Realität sieht meist anders aus. Da sollen die Coreprogrammierer halt auch die GUI basteln
Verstehen müssen sie die GUI so oder so.
Zuletzt bearbeitet von antialias am 17:05:32 17.09.2010, insgesamt 1-mal bearbeitet
ist eh kein definierter Begriff :-)
für mich heisst Low-Level, ich kann laufzeiten des Codes abschaetzen.
Also nicht low-level heisst für mich, Ich kann nicht mehr garantieren, das mein Prozess, wenn er den Fokus bekommt, das tut was ich denke, sondern er kann andere Dinge tun (bsp. Java, er raeumt erst mal seine GC's auf ...).
Unterschied in der Programmierweisse:
bei low level: ich designe vom Code her, d.h. ich hab ne genaue vorstellung von der Laufzeit, wenn ich den Code noch schreibe.
bei nicht low level: Ich muss erst mal funktionen ausmessen, was die mich kosten, laufzeittechnisch. Und selbst das muss dann nicht gleichbleibend sein. Ergo, ich kann nur implementieren, und dann die gesamtheit der funktionalitaet auf laufzeitverhalten testen, und dann entscheiden ob es langt oder nicht.
Ist halt viel probieren dabei.
Zitat:
Für mich ist C++ keine Low-Level Sprache, sondern eine Hochsprache die Low-Level zulässt.
Für mich ist C++ auch eine Hochsprache, mit der man aber auch low level(systemnah) programmieren kann. Das, in Kombination mit einigen, zugegeben nicht immer perfekten, stylistischen Mittel zum schreiben von sauberen Code ist aber das "Feature" von C++ schlechthin.
Zitat:
Jedes größere Projekt sollte vor allem pflegbar sein.
RIchtig. Und c++ ist IMHO die einzige Programmiersprache, wo man durch performanceprobleme "nicht intuitiv lesbaren Code" so gut verpacken kann. BlackBox-Programmierung in Kombination mit Performanter-Programmierung. Ich verlange von keinem Programmierer, das ich all seinen code verstehen muss, wenn er es "ordentlich" verpackt, also ein sauberes Interface bietet und das gut dokumentiert ist, und auch seiteneffektfrei ist.
Sprich, der code selber ist nicht unbedingt wartbar, aber dafuer iss das komplette Ding (Klasse/Methode) ohne Probleme austauschbar.
Das ist IMHO das Killerfeature von C++. Alles andere ereiche ich mit anderen Programmiersprachen besser.
Zitat:
Für mich gehören beispielsweise Zeiger zwar nicht zwangsweise gemieden, aber sind dennoch an vielen Stellen unnötig
C++ Designerichtlinien: Zeiger nur wo man muss, ansonsten Referenzen.
Also man sollte schon einen nichtwiderlegbaren Grund fuer einen Zeiger haben.
In schlechten c++ Code sind aber meist nicht die Zeiger schlechthin das Problem, sondern das damit oft verbundene new !
und new ist einer der laufzeitperformancekiller schlechtin ! Wer das ohne triftigen Grund verwendet, zu dem darf man getrost "Java-Programmierer" sagen
Ciao ...
Zuletzt bearbeitet von RHBaum am 11:04:36 21.09.2010, insgesamt 1-mal bearbeitet
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Sie können Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum antworten. Sie können Ihre Beiträge in diesem Forum nicht bearbeiten. Sie können Ihre Beiträge in diesem Forum nicht löschen. Sie können an Umfragen in diesem Forum nicht mitmachen.
c++.de ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums
für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de
Werbekostenerstattung verdient werden kann.
Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info, www.c-sar.de, www.c-plusplus.net und www.baeckmann.de
enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt
(vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in
privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden.
Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere
übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.
Twitter
Facebook
Ich mein, das kann passieren, aber kann man das als ernsthaftes Argument durchgehen lassen? Schwierig, würde ich sagen.
