Qt versus Mono & Java

[clue]

Beim Durchstöbern der Heise news bin ich auch auf folgende Meldung gestoßen:

http://www.heise.de/open/Technical-Prev ... ung/145083

Jetzt habe ich folgende Frage: Wenn Qt plattformunabhängig ist, läuft es dann auf allen Plattformen gleich gut? Und was ist dann besser (im Sinne von sicherheit, performance, look and feel und programmierbarkeit), Qt, Java oder Mono?

[GoKi]

Qt ist ein Toolkit (C++), das es für verschiedene Plattformen gibt. Java und Mono sind Programmiersprachen. Insofern kann ich den Vergleich nicht ganz nachvollziehen.
Auch andere Toolkits sind für verschiedene Plattformen verfügbar. Nur ob der C++ Quelltext dann auch auf der anderen Plattform kompiliert ist natürlich eine andere Sache.

[gms]

Wenn Qt plattformunabhängig ist, läuft es dann auf allen Plattformen gleich gut?

ja

Und was ist dann besser (im Sinne von sicherheit, performance, look and feel und programmierbarkeit), Qt, Java oder Mono?

hier kann man natürlich keine objektive Antwort drauf geben, außerdem ist Qt eine Klassenbibliothek für C++, für die es auch Bindings für Java (QtJambi) und Mono (Qyoto) gibt. Ich gehe daher jetzt einmal davon aus, daß du eigentlich die Programmiersprachen C++, Java und C# (Mono) und die verwendeten Laufzeitumgebungen: Qt-native Gui/Qt-Gui Emulation, Java und Mono vergleichen möchtest.

Plattformunabhängigkeit:
Hier hat Java einen Vorteil gegenüber Mono. Mono hinkt der aktuellen Implementierung des .Net Frameworks klarerweise immer hinterher und steht auch nur auf den wichtigsten Plattformen in brauchbarer Form zur Verfügung. Qt ist auch auf mehreren Plattformen verfügbar.

Sicherheit
Bei Java bzw Mono ist es naturgemäß schwerer unsicheren Code zu schreiben, durch das Einschalten von speziellen Compiler-Freatures ( position independend Executables (PIE), Stack-Smashing Protector (SSP), Fortify Source, sicherheits Warnungen ) können aber auch unter C++ sichere Programme erzeugt werden.

Performance
Bei der Performance hat C++ einen kleinen Vorteil ( bezogen auf den Startvorgang des Programms sogar einen großen Vorteil ). Schlimm wird es bei Java z.B wenn die Grafikbibliothek Swing verwendet wird, ansonsten können aber auch unter Java und Mono sehr performante Programme geschrieben werden.

Look and Feel
kommt bei Java und Mono hauptsächlich auf die verwendete Grafikbibliothek an, bei Qt auf die Plattform ( z.B sehr gut unter Windows und natürlich KDE, weniger gut unter Grnome) an

Programmierbarkeit
Was verstehst du darunter ?

Gruß
gms

[clue]

hmmm ... Danke, Euch beiden. jetzt verstehe ich es ein bisschen besser. Aber so richtig verstanden, was es dann mit Qt auf sich hat, habe ich noch nicht. Ich werd das mal bei wikipedia nachschlagen.

[Milbret]

Hallo,
als Entwickler möchte ich mich auch mal äußern.
Dein Vergleich ist etwas ungünstig.
Eigentlich kann man QT nicht mit Mono und Java vergleichen.

Mono und Java sind 2 Frameworks die eigentlich Systemfunktionen kapseln und in einer eignene Programmiersprache zur Verfügung stellen.
QT hingegen ist ein Framework das nur für GUI Entwicklung gedacht ist und somit nur die Systemfunktionen für die UI kapselt.

Man kann deshalb QT und Mono/Java nicht zusammen vergleichen.
Java und Mono gegenüber zu stellen ist da schon eher möglich und sinnvoll, da Mono(.Net) ein Konkurent zu Java werden soll.
Nur war .Net eigentlich nur für die Kapselung der Windows API gedacht.
Heute würde sich kein Mensch mehr ransetzen und die C Funktionen von Windows nutzen wollen um sich per C Win API Programme zu schreiben.
Ich habe mir selbst mal zum testen die C Win API angeschaut und auch ein kleine Framework in C++ geschreiben.
Trotzdem würde ich dies nicht mehr machen und lieber auf C# setzen wenn ich unter Windows only Programmieren üwrde.
Ansonsten wenn es Crossplatform sein soll, nimmt man Java.

QT ist, wie gesagt, eher was für GUI Anwendungen und somit eher etwas mit Swing vergleichbar.
Aber hier bin ich nicht so sicher.

Martin

[gms]

QT hingegen ist ein Framework das nur für GUI Entwicklung gedacht ist und somit nur die Systemfunktionen für die UI kapselt.

ein großer Teil des Qt Frameworks ist sicherlich der GUI Entwicklung zuzuordnen, aber von einem Framework, daß nur das User Interface kapselt, ist Qt auch weit entfernt:
http://de.wikipedia.org/wiki/Qt_%28Bibl ... heksaufbau

Gruß
gms

[Milbret]

Ah mein Fehler.
Leider bin ich nicht der Experte für QT aber nicht schlecht was QT si bietet.
Trotzdem würde ich es nicht mit Mono und Java Vergleichen, auch wenn die Bibliotheken von QT schon sehr stark in die Richtung von Mono und Java gehen.

Martin

[peschmae]

Ich finde einen derartigen Vergleich - also C++ mit Qt vs Java mit Swing vs C#/Mono durchaus gerechtfertigt. Schliesslich muss sich jeder, der eine GUI-Software für Windows, Mac und Linux/Unix diese oder eine ähnliche Frage stellen. Klar sind Mono/JRE und Qt etwas fundamental unterschiedliches - aber wenn man sich zwischen Äpfeln und Birnen entscheiden will oder muss, dann ist es durchaus angebracht Äpfel mit Birnen zu vergleichen.

Vorteile von Java imo:
- Plattformunabhängigkeit ohne neu kompilieren (solange man nur im Rahmen des Java Frameworks arbeitet...)
- sehr gute Dokumentation der Klassenbibliotheken
- einfaches Debugging der Programmiersprache (i.E. automatische Stacktraces mit Zeilennummern bei Exceptions)
Nachteile:
- ich mag das Look and Feel der GUIs nicht

Vorteile von C++/Qt:
- ähnlich umfangreiche und gut dokumentierte Klassensammlung wie Java die genauso alles notwendige abdeckt
- einfachere Erweiterbarket mit Funktionalität aus externen Bibliotheken (wobei man da dann natürlich selber auf Plattformunabhängigkeit achten muss)
- sehr flexible Programmiersprache, *richtige* Templates sind auch nicht zu verachten
- das Look and Feel der GUIs gefällt mir auf Unix und Windows deutlich besser als bei Java (k.A. von Mac...)
- vergleichsweise (mit Java) schneller Programmstart; zur Laufzeit kann ich heutzutage auf aktuellen Rechnern und mit Java Versionen ab 1.5 nicht mehr wirklich einen Tempounterschied sehen
- macht C++ GUI praktisch so komfortabel wie Java (wenn man das so sagen darf ohne erschlagen zu werden )
Nachteile:
- C++ darf man durchaus auch nicht mögen - alternativ kann man aber auch sehr gut Python und PyQt verwenden. Oder so.

Mono/C#:
- Benutze ich nicht - keine Ahnung davon. Ist etwas unangenehm weil man immer der Microsoft Entwicklung hinterherhinkt (so wie das früher auch bei den freien Java Implementierungen und Sun der Fall war) und zudem die Plattformunabhängigkeit nur durch Mono (und dotgnu) erreicht wird.

MfG Peschmä

[clue]

Vorteile von Java imo:
- Plattformunabhängigkeit ohne neu kompilieren (solange man nur im Rahmen des Java Frameworks arbeitet...)
- sehr gute Dokumentation der Klassenbibliotheken
- einfaches Debugging der Programmiersprache (i.E. automatische Stacktraces mit Zeilennummern bei Exceptions)
Nachteile:
- ich mag das Look and Feel der GUIs nicht

Danke, Du sagst es! Jdownloader fühlt sich sehr fremd an. Außerdem ist die GUI extrem träge und Prozessorintensiv (zumindest bei mir) . Obwohl ich sagen muß, die neue GUI hat schon einiges an performance gebracht.

Vorteile von C++/Qt:
- ähnlich umfangreiche und gut dokumentierte Klassensammlung wie Java die genauso alles notwendige abdeckt
- einfachere Erweiterbarket mit Funktionalität aus externen Bibliotheken (wobei man da dann natürlich selber auf Plattformunabhängigkeit achten muss)
- sehr flexible Programmiersprache, *richtige* Templates sind auch nicht zu verachten
- das Look and Feel der GUIs gefällt mir auf Unix und Windows deutlich besser als bei Java (k.A. von Mac...)
- vergleichsweise (mit Java) schneller Programmstart; zur Laufzeit kann ich heutzutage auf aktuellen Rechnern und mit Java Versionen ab 1.5 nicht mehr wirklich einen Tempounterschied sehen
- macht C++ GUI praktisch so komfortabel wie Java (wenn man das so sagen darf ohne erschlagen zu werden )
Nachteile:
- C++ darf man durchaus auch nicht mögen - alternativ kann man aber auch sehr gut Python und PyQt verwenden. Oder so.

Also kann man mit Qt auch beliebige Programme basteln, wie z.B. Jdownloader? Oder ist Qt wirklich nur für die GUI zuständig? Wenn man mit Qt auch beliebige Programme basteln kann, dann konkurrieren 3 Lösungen um ein und das selbe Problem.

Sind eigentlich Mono/Java/Qt- Programme genauso performant, wie native Progs (wobei ich mich dann frage, was nativ eigentlich bedeuten soll). Wie werden denn normalerweise Spiele, Mediaplayer, eBanking, etc. Software unter Windows und Linux/Unix entwickelt? Alle Windows Progs mit .Net oder gibts auch was anderes (außer Java/Qt/Mono)? Und die Unix/Linux Progs, wie werden die entwickelt?

Sehen eigentlich Qt Programme, die unter Linux/Unix geschrieben worden sind, genauso aus, wie unter XP/Vista?

Ich weiß, das sind alles Anfänger Fragen ...

[Spasswolf]

Also kann man mit Qt auch beliebige Programme basteln, wie z.B. Jdownloader? Oder ist Qt wirklich nur für die GUI zuständig?

Qt kann noch mehr als Gui: http://doc.trolltech.com/4.5/index.html,
und mit C++ kann man beliebige Programme mit Qt Gui (und anderen Qt Libraries) basteln.

Sind eigentlich Mono/Java/Qt- Programme genauso performant, wie native Progs (wobei ich mich dann frage, was nativ eigentlich bedeuten soll).

Qt Programme sind native Programme.

[gms]

Also kann man mit Qt auch beliebige Programme basteln, wie z.B. Jdownloader?

klar, Qt ist ein Application Framework und kein Gui Wrapper

Wenn man mit Qt auch beliebige Programme basteln kann, dann konkurrieren 3 Lösungen um ein und das selbe Problem.

wieso 3 ? Alleine für C++ gibt es noch viele weitere Frameworks, wie z.B wxWidget, Fox, fltk, mozilla, gtkmm, ... und auch Programmiersprachen gibts wie Sand am Meer

Sehen eigentlich Qt Programme, die unter Linux/Unix geschrieben worden sind, genauso aus, wie unter XP/Vista

wie du möchtest, bzw wie der Anwender es am liebsten hat, per Option kann zwischen den verschiedenen Darstellungen umgeschaltet werden:
http://doc.trolltech.com/4.5/qstyle.html#details

Sind eigentlich Mono/Java/Qt- Programme genauso performant, wie native Progs (wobei ich mich dann frage, was nativ eigentlich bedeuten soll).

es gibt auch unperformante native kompilierte Programme und performante Programme die eine Java/Mono Laufzeitumgebung brauchen

Wie werden denn normalerweise Spiele, Mediaplayer, eBanking, etc. Software unter Windows und Linux/Unix entwickelt? Alle Windows Progs mit .Net oder gibts auch was anderes (außer Java/Qt/Mono)? Und die Unix/Linux Progs, wie werden die entwickelt?
Ich weiß, das sind alles Anfänger Fragen ...

stimmt , von Javascript bis zu Assembler ist da alles möglich

Gruß
gms

[catdog2]

es gibt unperformante native kompilierte Programme und performante Programme die eine Java/Mono Laufzeitumgebung brauchen

Was man leider für die GUI bei java nicht sagen kann. Die reagiert eigentlich immer wie eine schlaftablette.

[michaels]

es gibt unperformante native kompilierte Programme und performante Programme die eine Java/Mono Laufzeitumgebung brauchen

Was man leider für die GUI bei java nicht sagen kann. Die reagiert eigentlich immer wie eine schlaftablette.

Unsinn.
Ich programmiere selbst Java (u.a. auch GUIs mit Swing). Und wenn man die einigermaßen vernünftig programmiert, merkt man da (heute) keinen Unterschied mehr.
Zum Teil wohl auch durch die schnelleren Rechner, aber auch Java selbst hat sich in den letzten Jahren deutlich gesteigert.

[Barret7777]

Also so wie ich das sehe handelt es sich bei Java und Mono um Plattformunabhängige Virtuelle Maschienen. Die JVM (Java Virtual Machine) verwendet Java als Programmiersprache und Mono wird mit C# programmiert.
Der jeweilige Compiler übersetzt den geschriebenen Code in Bytecode und dieser wird zur Laufzeit vom JITC (Just in Time Compiler) für das jeweilige Betriebssystem übersetzt.
Java ist meiner Meinung nach kein Framework sondern kann selbst mithilfe von Frameworks z.B Swing, QT Jambi, AWT programmiert werden.

Man kann QT und Java/Mono deshalb nicht Vergleichen weil es sich bei QT um eine C++ Klassenbibliothek handelt die die jeweiligen Funktionen des Betriebssystems aufruft und bei Java/Mono die Virtuelle Maschiene (die bei Java übrigens in C geschrieben ist) dies übernimmt.

Bitte berichtigt mich, bin mir selber nicht ganz im klaren wie das ganz Funktioniert.

Weiss jeman warum QT eigentlich ein Wrapper ist, und ob QT direkt auf der WINAPI und dem X-Server aufsetzt?

[Milbret]

Kleine Zusammenfassung.

QT -> C++ geschreiben ähnlich der Java API oder C# API für Crossplatform Entwicklung.
Java -> Programmiersprache
JVM -> Virtuelle Maschine/Laufzeitumgebung für Java Programme.

C# -> Programmiersprache
VB .Net -> VB mit Anbindung an .Net also Basic mit API von .NET.
Mono -> Virtuelle Maschine/Laufzeitumgebung für C# sowie VB .Net Programme.

Hoffe die Zusammenfassung ist vollständig.
Mono und QT sind beide in C++ geschreiben wärend Java eher in C aufgeht,

Den Vergleich kann man teilweise machen.
Java, C# und QT bieten alle samt eine API für Crossplatform Entwicklung an.

Wären Mono und Java eher auf eine eigene Laufzeitumgebung mit VM arbeitet und die Bytecode sogar noch per JIT Compiler in Nativen Code übersetzt, hat man bei QT bereits nativen Code beim übersetzen des Programms.

Vorteil bei QT ist, dass man die Programme durch die einheitliche API ohne Probleme auf andere OS portieren kann, wenn die entsprechenden QT Libs vorhanden sind und man keine Systemspezifischen Aufrufe in seinem Code nutzt bzw. diese ebenfalls für Crossplatform Entwicklung per Präprozessor je nach System einbinden lässt.
Bei Java und Mono hingegen muss man nur den Bytecode als minimum liefern was auch die fertigen Programme recht klein hält.

Mein einfaches Backup Tool brauch allein als .jar ohne die zusätzlichen jar Archive nur 40 Kbyte.
Bei Mono Programmen läuft es ähnlich.

Ansonsten sollte doch nun alles klar sein oder?

Ansonsten empfiehlt sich folgendes:
http://de.wikipedia.org/wiki/Java_%28Pr ... sprache%29
http://de.wikipedia.org/wiki/Mono-Projekt
http://de.wikipedia.org/wiki/Common_Lan ... astructure
http://de.wikipedia.org/wiki/.NET
http://de.wikipedia.org/wiki/Qt_%28Bibliothek%29

Ist zwar etwas viel Lesestoff aber danach sollte einiges klarer werden, bzw. kann man in meinem Text enthaltene Fehler beheben

Martin

[armin]

Nur um kurz ein klitzekleines Bisschen Klugzuscheißen: Es ist Qt (theoretisch gesprochen Cute, auch wenn ich das irgendwie seltenst erlebe) und nicht QT. QT kommt aus der Apfel-Welt und ist für andere Dinge gedacht.

[Milbret]

Oh mein Fehler

Martin

[clue]

Oh je! Jetzt ist schon wieder ein neuer Player im Multi-Plattform-Reigen aufgetaucht (naja, zumindest neu für mich ): http://de.wikipedia.org/wiki/OpenCL.

Also nochmal für mein armes, kleines Hirn:

- QT & GTK um grafische Anwendungen zu programmieren
- Java, Mono und C++ um auch andere Sachen zu machen

Und OpenCL soll jetzt auch noch mitmischen? Klingt irgendwie so, als ob man zukünftig vielleicht sogar ganz auf Mono/.Net & Java verzichten könnte, oder?

[gms]

Klingt irgendwie so, als ob man zukünftig vielleicht sogar ganz auf Mono/.Net & Java verzichten könnte, oder?

nein, eigentlich überhaupt nicht
OpenCL steht zu .Net bzw Java nicht in Konkurrenz, da hast du etwas völlig falsch verstanden. Sollten .Net bzw Java Applikationen Bedarf an OpenCL haben, dann wird ( oder wurde ) dieses Problem wahrscheinlich durch entsprechende Bindings gelöst

Gruß
gms

[clue]

Klingt irgendwie so, als ob man zukünftig vielleicht sogar ganz auf Mono/.Net & Java verzichten könnte, oder?

nein, eigentlich überhaupt nicht
OpenCL steht zu .Net bzw Java nicht in Konkurrenz, da hast du etwas völlig falsch verstanden. Sollten .Net bzw Java Applikationen Bedarf an OpenCL haben, dann wird ( oder wurde ) dieses Problem wahrscheinlich durch entsprechende Bindings gelöst

Gruß
gms

Ach so. Dann ist OpenCL die unterste Schicht, auf die andere Programme zugreifen können, wie eine Art Abstraktionsschicht? Und diese kümmert sich nur um die Berechnungen, so daß die Programme sich selbst nicht die Mühe machen müssen, ihre Rechenaufgaben auf die verschiedenen CPUs/GPUs aufzuteilen?

[crischi]

Echte Programmiersprachen werden auf der Zielplattform compiliert (notfalls auch Crosscompiler). Aber immer COMPILIERT! Harter Maschinencode für harte Männer! Echte Männer räumen auch Ihren Dreck hinterher weg und beanspruchen keine Putzfrau namens Gabi Kollektor. Kurz und knackig, ein Buchstabe, keine Vokale. Echte Männer eben!


lg
crischi.

[Milbret]

Echte Programmiersprachen werden auf der Zielplattform compiliert (notfalls auch Crosscompiler). Aber immer COMPILIERT! Harter Maschinencode für harte Männer! Echte Männer räumen auch Ihren Dreck hinterher weg und beanspruchen keine Putzfrau namens Gabi Kollektor. Kurz und knackig, ein Buchstabe, keine Vokale. Echte Männer eben!


lg
crischi.

Du betreibst nicht zufällig beruflich Softwareentwicklung oder?
Den beruflich will ich mit solchen Aussagen nichts zu tun haben :/
Ich bin sogar privat nur noch sehr selten dazu gewillt mit nativer programmierung zu arbeiten.
Aber zu deinem "echte Programmiersprachen" solltest du wissen, dass Javas Bytecode und der .Net/Mono IL/MSIL Code ebenfalls kompiliert wird.
Nur als kleiner Hinweis zu dem kompilieren.

Anbei sollte man kompilieren und nicht compilieren schreiben.
Deutsche Rechtschreibung WTF

Martin

[bmario]

...
nativer programmierung
...
Anbei sollte man kompilieren und nicht compilieren schreiben.
Deutsche Rechtschreibung WTF

Sollte wohl "nativer Programmierung" heißen.

SCNR

[Milbret]

...
nativer programmierung
...
Anbei sollte man kompilieren und nicht compilieren schreiben.
Deutsche Rechtschreibung WTF

Sollte wohl "nativer Programmierung" heißen.

SCNR

Danke für den Hiwneis

Martin

[crischi]

Es kommt immer auf die Plattform an, Java ist nicht das Allheilmittel, dass alle gerne hätten. C-Programmierung hat auch etwas mit Disziplin zu tun. Man kann sehr wohl auch mit C++ und sogar mit C ansatzweise 'objektorientiert' programmieren. Ich bin eben der Hardware sehr viel näher. Versuch mal auf einem µC mit 8kB ROM und 2kB RAM eine virtuelle Maschine zu installieren.

Jungs, seht die Welt nicht immer ganz so tierisch ernst! Jedem Tierchen sein Pläsierchen...
Der Duden kann mich mal. Ich schreib schon immer 'compilieren', sonst muss ich ja umdenken, und dann vergess' ich deshalb wohl noch die Formatoptionen von 'printf', nä, nä, nich' mit mir.

Achso, wir kommen vom Thema ab...


lg,
crischi