.NET und C# Pro und Contra

Siberian..Husky schrieb:
Zum speichern von einstellungen gibts bei Qt die QSettings klasse. diese nutzt unter windows die registry, unter mac die carbon preferences api(wo auch immer die den kram dann speichert ;)) und unter allen anderen betriebsystemen textdateien.
Dann ist GTK+ echt nicht so das wahre. Man merkt irgendwie, dass hinter Qt auch ein kommerzieller Gedanke steckt. Leute geben kein Geld für einen Scheiß aus.

Siberian..Husky schrieb:
es gibt einen QStyle unter windows der die windows XP themes nutzt. verwendet wird dabei allerdings eine eigene redering engine wie bei allen QStyles. ich glaube allerdings nicht das diese groß langsamer ist als windows selbst. zumindest habe ich noch kein Qt programm gesehen das eine träge ui hatte. der vorteil dabei ist das alle widgets echte klasse sind und man somit durch vererbung 100% des verhaltens ändern kann, was über die windows-api nicht möglich ist. SWT und .net machen das soweit ich weiß genauso.
MFC und WTL sollten eigentlich genau das gleiche machen. Es ist auch per Win32 API möglich allerdings recht aufwändig das Verhalten von Widgets anzupassen. Man kann se aber nicht einfach per Vererbung verändern.

Bei C# muss es auch sowas wie protected oder private geben,

apropos Qt und GTK+... für GTK+ braucht man ebenfalls Runtime Komponenten in Form von DLLs (hab neulich mal GIMP für Window runtergeladen). Ist das bei QT auch so oder kann ich komplett alles einkompilieren wenn ich will? Vor allem wie wirkt sich das dann auf die Binary Größe aus?
 
Zuletzt bearbeitet:
man kann alles wo man den source zu hat auch eincompilieren. das geht auch mit gtk. nur macht es wenig sinn. da dlls wesentlich resourcenschonender sind(die liegen nur einmal im speicher, selbst wenn mehrere programme sie nutzen.).

allerdings kann man dlls nicht mit einer runtime vergleichen.

wie sich das eincompilieren von qt auf die größe auswirkt kann ich leider nicht sagen da ich haubtsächlich unter windows programmierer und es von der windows qt version leider keine sourcen gibt(ausser man kauft eine lizens, aber die is mir dann doch zu teuer :P).
die größe lässt sich dann allerdings eh nicht pauschal sagen. wenn man statisch linkt kommt nur das ins binary was man wirklich auch benutzt, da Qt sehr viele klasse hat wird eine statischgelinkte qtlib wesentlich kleiner sein als die dll - da es ziemlich ausgeschlossen ist das ein programm wirklich alle features nutzt. allerdings spielt auch der compiler eine große rolle. die optimierte version der qt dll ist ca. 3mb groß, die ohne optimierungen ist mit etwa 6mb fast doppelt so groß.

P.S.: man kann Qt nicht mit gtk+ vergleichen. gtk+ ist eben nur für die gui. alle gnome klassen die nichts mit der gui zutun haben sind in extra bibliotheken untergebracht, diese sind allerdings teilweise nicht plattformunabhängig. trotzdem sind diese bibliotheken nicht schlechter als Qt. beides hat seine vorteile. die libxml von gnome z.b. ist die schnellste xml bibliothek die es derzeit gibt, und bei weitem schneller als die von Qt. dafür is das interface dank c aber alles andere als benutzbar :P.

P.P.S.: mit den mfc und wtl lassen sich genauso wie mit der winapi nur wenige windows controls anpassen. den ownerdraw modus können soweit ich weiß fast nur buttons, customdraw trees und listen. allerdings lässt sich selbst damitdas verhalten nur schwer anpassen. und der code wird am ende alles andere als schön.
 
Siberian..Husky schrieb:
...
allerdings kann man dlls nicht mit einer runtime vergleichen.
Nennt sich aber dennoch GTK+ Runtime Environment.
Prinzipiell passt das aber schon, denn es wird ja während der Laufzeit verwendet.

Siberian..Husky schrieb:
wie sich das eincompilieren von qt auf die größe auswirkt kann ich leider nicht sagen da ich haubtsächlich unter windows programmierer und es von der windows qt version leider keine sourcen gibt(ausser man kauft eine lizens, aber die is mir dann doch zu teuer :P).

Siberian..Husky schrieb:
P.S.: man kann Qt nicht mit gtk+ vergleichen. gtk+ ist eben nur für die gui. alle gnome klassen die nichts mit der gui zutun haben sind in extra bibliotheken untergebracht, diese sind allerdings teilweise nicht plattformunabhängig. trotzdem sind diese bibliotheken nicht schlechter als Qt. beides hat seine vorteile. die libxml von gnome z.b. ist die schnellste xml bibliothek die es derzeit gibt, und bei weitem schneller als die von Qt. dafür is das interface dank c aber alles andere als benutzbar :P.
Qt scheint aber sauberer programmiert zu sein wenn man Feedback drüber liest. Ich werd beides demnächst ausprobieren glaub ich. Mit Win32 API werd ich nicht glücklich, mit MFC und WTL komm ich nicht richtig klar, vielleicht klappts ja mit Qt oder GTK besser.

Jetzt weiß ich auch, dass Qt wirklich umfassend ist, danke.

Ist die xmllib plattformunabhängig?

Siberian..Husky schrieb:
P.P.S.: mit den mfc und wtl lassen sich genauso wie mit der winapi nur wenige windows controls anpassen. den ownerdraw modus können soweit ich weiß fast nur buttons, customdraw trees und listen. allerdings lässt sich selbst damitdas verhalten nur schwer anpassen. und der code wird am ende alles andere als schön.
Ich hab noch nie schönen Windows Code gesehen.
MFC ist für mich alles andere als durchsichtig und WTL erweckt nur den Anschein von STL Ähnlichkeit.

Danke soweit mal. Sorry für so viel OT.
 
die MFC is mitlerweielwirklich veraltet. überall kommt erben die win-api noch durch, das is echtes c++ kaum möglich. wtl nutz ich gerne für kleinere programme oder plugins wo man normalerweise auch nur win-api benutzt. allerdings sind die abhängigkeiten von der atl etwas störend.

die xmllib gibts zumindest auch für windows und mac. sollte also ziemlich unabhängig sein. allerdings würde ich das ding wirklich nur empfehlen wenn man zeitkritische sachen macht. die c-api is einfach müll, wie jede andere c-api auch :P

@topic: weiß den niemand ob asp.net mit c# auch über mono/apache funktioniert? das wäre der einzig sinnvole einsatzzweck den ich derzeit für .net habe ;).
 
Zurück
Oben