Boost vs. QT
-
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.
-
Warum sprecht ihr von Abhängigkeiten von der C-Standardbibliothek?
-
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.
-
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.
-
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.
-
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.
-
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
-
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 ...
-
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
-
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.
-
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 ...
-
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.
-
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 unrechtIch 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 ...
-
RHBaum schrieb:
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).
-
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.
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)
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.
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.
-
Definiere bitte mal Low-Level.
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.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.
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.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 ...
