C/C++ Forum :: Boost vs. QT

RHBaum Mitglied 14:58:26 17.09.2010 Titel:

Zitat:

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

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

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

Ciao ...

asc Mitglied 15:19:26 17.09.2010 Titel:

antialias schrieb:

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

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

antialias schrieb:

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

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

antialias schrieb:

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

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

RHBaum Mitglied 15:30:23 17.09.2010 Titel:

Zitat:

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 ...

asc Mitglied 17:01:13 17.09.2010 Titel:

RHBaum schrieb:

Zitat:

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).

antialias Mitglied 17:04:11 17.09.2010 Titel:

Zitat:

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.

RHBaum Mitglied 11:03:48 21.09.2010 Titel:

Zitat:

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.

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 ...