Herb Sutter - The Future of C++
-
Hallo,
bitte führt die Diskussionen zum Thema C# vs. C++ vs. Java in einem Extrathread im RUDP-Forum. Dieser Thread hat bereits ein anderes Thema. Und wir Programmierer sollten wenn möglich immer nach "high cohesion" streben, also "ein Thread - ein Thema".
-
Power Off schrieb:
nman: Geht bestimmt auch unter Linux, wenn Du Dir das Windows-Codec-Paket fuer XINE installierst.
Von xine halte ich nix, und der mplayer gibt das natürlich wieder, aber die Qualität ist eben ziemlich bescheiden.
-
Es mag ja sein, dass .NET ein ECMA-Standard ist, aber das ist angesichts der vielen Patente, die Microsoft auf .NET hält bzw. erhalten will (manche sind noch im application-Stadium), recht egal. Was meint ihr wohl, warum MS sich nicht ans w3c gewendet hat? Die erlauben keine patentierte Software in ihren Standards.
Siehe dazu z.B. http://www.heise.de/newsticker/meldung/34434
Mit anderen Worten - das mit C# und Plattformunabhängigkeit halte ich für ein Gerücht.
Was das Video angeht, die Qualität ist wirklich grottig. Das man nichts sieht, ist ja OK, aber dass das Weißrauschen im Hintergrund bald lauter als die Sprache ist...ich hab jedenfalls nur so zwei Drittel verstanden. Jedenfalls hab ich ausgeschaltet, als er (wenn ich das richtig verstanden habe, es war, wie gesagt, nicht sonderlich gut zu hören) anfing, generics und templates über den selben Kamm zu scheren. Wenn ich das richtig verstanden habe, hat er das generische Programmierparadigma (das generics nicht umsetzen) nicht verstanden, was seine Meinung über die Zukunft von C++ für mich ziemlich unerheblich macht.
-
0xdeadbeef schrieb:
Jedenfalls hab ich ausgeschaltet, als er (wenn ich das richtig verstanden habe, es war, wie gesagt, nicht sonderlich gut zu hören) anfing, generics und templates über den selben Kamm zu scheren. Wenn ich das richtig verstanden habe, hat er das generische Programmierparadigma (das generics nicht umsetzen) nicht verstanden, was seine Meinung über die Zukunft von C++ für mich ziemlich unerheblich macht.
Du hast hier scheinbar nicht zwei Drittel nicht sondern absolut gar nichts
verstanden. Weder kehrt er Generics und Templates über den selben Kamm noch behauptet sie seien äquivalent. Und über generischer Programmierung redet er auch nicht.Er sagt an der Stelle, dass C++ die Systemsprache von .Net ist und das C++ die Sprache ist, die dem Programmierer die meisten Möglichkeiten zur Verfügung stellt (sie kommt am Nächsten an die virtuelle Maschine ran).
Dann bringt er ein Beispiel: nämlich Generics und zwar ganz speziell Generic-Types. Die sind ein neues Feature in .Net 2. In C++ hingegen sind Generic-Types aber in Form von Templates nichts neues. Allerdings sind Templates im Gegensatz zu Generics nicht "cross-language"-fähig. D.h. du konntest zwar in Managed-C++ Templates verwenden, diese aber nicht anderen .Net-Sprachen zur Verfügung stellen (was mit den runtime-Generics natürlich geht). Er sagt dann extra, dass er nicht weiter in die Richtung "Templates vs Generics" (oder deren Äquivalenz) bohren möchte sondern dass es vielmehr wichtig ist nicht eines der beiden Features als "besser" als das andere darzustellen. Keines ist inhärent besser. Templates und Generics sind verschieden aber komplementär.
Dann sagt er noch, und das ist jetzt der entscheidene Punkt, dass es cool ist beides zu haben und das man Generics zwar in allen .Net-Sprachen benutzen kann (C#, VB usw.), man in C++ aber diesbezüglich weitrechende Möglichkeiten hat, da C++ mehr der "underlying features" zur Verfügung stellt. Sprich: Generics aus Sicht der CLR bieten mehr Möglichkeiten als die Sprachen C# und VB zur Verfügung stellen. C++ hingegen gewährt vollen Zugriff.
Den Punkt den er macht ist der, dass C++ mit seiner Design-Philosophie "Trust the programmer" flexibler als andere Sprachen ist. Diese Flexibilität ist aber auch nicht immer ein Vorteil, wie er ja später auch noch erklärt.Wenn ich das richtig verstanden habe, hat er das generische Programmierparadigma (das generics nicht umsetzen) nicht verstanden, was seine Meinung über die Zukunft von C++ für mich ziemlich unerheblich macht
Also ich denke das du problemlos davon ausgehen kannst, dass Herb Sutter (einer der C++ Top-Experten, Autor von vier weltweit anerkannten C++ Standardwerken und unzähligen Artikeln sowie Vorsitzender des C++ Standardkomitees) generische Programmierung verstanden hat.
Da Herb Sutter die Entwicklung von C++ seit jahren intensiv verfolgt und
auch beeinflusst (mittlerweile gleich an zwei Fronten - einmal über CLI/C++ und einmal über das Standard-Komitee), denke ich, dass man seiner Meinung zum Thema "C++ in der Zukunft" schon gehör schenken sollte. Genauso wie der von solchen unbekannten Leuten wie Bjarne Stroustrup oder P.J. Plauger.
-
ich fand die qualität ganz in ordnung. und der ton war auch ok. kein großes rauschen oder unscharfe bilder...
muss sagen, ich fand den ersten teil recht interessant, die diskussion über das compiler framework war eher langweilig, da hätten es auch ein paar sätze getan
aber sutter hat ein paar gute punkte gebracht und mein vertrauen in c++/cli gestärkt
-
Die Qualität ist IMHO total mies. Der .wma Codec scheint wirklich geil zu sein, nach allem was ich so weiß, besser als mp3. Aber das .wmv haut mich jetzt wirklich nicht vom Hocker.
Mein Vertrauen in C++/CLI braucht insofern keine große Stärkung, weil C++ damit endlich ne vernünftige Standardbibliothek mit Objektserialisierung, Threads, Sockets und weiteren völlig elementaren Sachen bekommt und anständige Unterstützung für gewisse Features direkt auf Sprachebene. Die jetzige stdlib ist halt einfach affig und genau ein starker Grund, warum Standard C++ mich überhaupt nicht mehr reizt.
Das mit der Standardisierung ist aber IMHO nicht sehr viel mehr als eine PR-Geste. Die Klassenbibliothek vom .Net Framework ist nicht so wirklich high-level und abstrakt, man merkt an allen Ecken und Enden das WinAPI durch. Ich halte das in vielen Bereichen für schwierig zu portieren.
Und das irgendjemand anders demnächst noch einen C++/CLI Compiler entwickelt, halte ich auch eher für fraglich. Ich glaube also schon, dass sich das Ganze in der Praxis als starke Bindung an Windows erweisen wird.
-
HumeSikkins! Danke für die Zusammenfassung. Auch ich denke nicht, das Sutter nicht weiß wovon er spricht. Sonst hätte ich das hier auch nicht gepostet.
Optimizer! Yo, wenn C++0x nicht ordentlich nachlegt wird es für C++ sehr schwer werden. C++/CLI ist fast schon ein inoffizieller Nachfolger in meinen Augen. Vorallem mit der C++/CLI 2.0 Syntax ist es wirklich "schön" geworden.
-
Der Vollständigkeit halber hier der zweite Teil:
-
OK, Herb Sutter mal außen vorgelassen - da kann es wirklich gut sein, dass ich es einfach nicht richtig gehört habe; xine wollte den Ton überhaupt nicht abspielen und mplayer nur mit sehr starkem Rauschfaktor - in C++/CLI oder .NET allgemein kann ich kein großes Vertrauen setzen. Ich sehe keine Garantie für Plattformunabhängigkeit, die für einen Standard ein Muss ist, und auch, dass man das WinAPI an allen Ecken durchmerkt, ist imho nicht besonders vorteilhaft. Das sind allerdings implementierungsspezifische Fragen bezgl. .NET, deswegen will ich mich damit nicht länger aufhalten.
Man hört ziemlich häufig, dass die STL für eine Programmiersprache als Standardbibliothek nicht ausreichend sei. Es ist zwar richtig, dass die STL nicht den Featureumfang bietet wie z.B. die JFC, aber das ist ja auch per Design so. Der Grundansatz von C++ ist nicht monolithischer Struktur, deswegen hat man auch nicht alles in den Standard einbezogen. Das hat auch seinen Sinn, auch wenn der in Zeiten von Java & Co. wenig Beachtung findet.
Es gibt mit Sicherheit einige Dinge, die in einer Standardbibliothek ihren Platz hätten - Objektserialisierung ist ein gutes Beispiel, und Threads könnte man inzwischen wohl auch einbinden - aber gerade eine Grafikbibliothek ist ein gutes Beispiel für etwas, das da einfach nicht reingehört. Das aus dem einfachen Grund, dass eine Standardbibliothek auf allen Systemen lauffähig sein muss (bzw. sollte), und es jede Menge Systeme gibt, auf denen kein grafisches Subsystem vorhanden ist. Es mag zwar sein, dass Windows das Grafiksystem in den Systemkern integriert hat (aus welchem Grund auch immer), aber nicht jeder Rechner braucht, und konsequenterweise hat nicht jeder Rechner ein Grafiksystem. Für die meisten Server ist Grafik völlig unerheblich und nur unnötiger Overhead.
Noch deutlicher ist das bei Sockets zu sehen. Ganz abgesehen davon, dass es schon seit den Siebzigern einen Standard gibt, der Sockets beinhaltet (POSIX), gibt es an der Stelle eine subtile Inkonsistenz im Denken derer, die alles in eine Standardbibliothek pressen wollen. Auf der einen Seite erwarten die Leute eine ultramoderne Klassenbibliothek, die ihnen so ziemlich alles abnimmt, auf der anderen Seite wollen sie auf ein derart archaisches Konzept wie Sockets zurückgreifen. Netzwerkkommunikation kennt viele Formen, und nur selten sind Sockets die beste Wahl. An der Stelle würde es noch deutlich mehr Sinn machen, CORBA zu integrieren, was angesichts des dadurch entstehenden Laufzeitoverheads natürlich auch so ziemlich keiner machen will.
Die grundsätzliche Frage, die dadurch aufgeworfen ist, ist, was eigentlich sinnvollerweise standardisiert werden sollte. Standardisierung ist ein zweischneidiges Schwert. Es hat den Vorteil, dass man sich als Coder auf etwas verlassen kann, hat aber den Nachteil, dass Flexibilität verloren geht und Wettbewerb unter verschiedenen Implementierungen stark eingeschränkt wird. Ein wunderbares Beispiel für die Nachteile der Standardisierung ist, wie lange X gebraucht hat, um transparente Fenster zu lernen, ein anderes, dass es neben AWT und Swing für Java nur ein nennenswertes Grafiktoolkit gibt, nämlich SWT - was auch nur sehr spärlich eingesetzt wird. Man sollte sich an der Stelle sehr gut überlegen, was man in Stein meißeln will.
-
0xdeadbeef schrieb:
Es gibt mit Sicherheit einige Dinge, die in einer Standardbibliothek ihren Platz hätten - Objektserialisierung ist ein gutes Beispiel, und Threads könnte man inzwischen wohl auch einbinden
Threads können nicht allein auf Bibliotheksebene integriert werden. Die Sprache muss schon ein Thread-Konzept kennen bzw. definieren.
Das wird für C++ aber hoffentlich auch bald der Fall sein, denn mit dieser "Threads-kenne-ich-nicht"-Einstellung wird C++ definitiv nicht ewig durchkommen.Ein anderes wichtiges Thema ist imo (optionale) GC. Und zwar mit sauberer Trennung zwischen Memory- und Ressourcemanagement, also ohne das auf Destruktoren verzichtet werden muss. GC ist ja auch im Zusammenhang mit Threads ein Bonus (siehe Lock-Free-Programming).
Die jetzige stdlib ist halt einfach affig und genau ein starker Grund, warum Standard C++ mich überhaupt nicht mehr reizt.
Den Punkt verstehe ich nicht. Es ist ja nicht so, dass ein C++ Programmierer als selbst programmieren muss, was nicht in der Standardlib enthalten ist. Es gibt einen riesigen Markt von C++ Bibliotheken. In allen Geschmacksrichtungen. Von akademisch über frei bis kommerziell bzw. professionell.
Dieser dezentrale Ansatz hat imo auch seine Vorteile.Es ist mir z.B. ein Rätsel wozu man eine Gui-Standardlib braucht. Nicht nur das so eine Lib imo ein Monsterding wäre, sie müsste auch am Besten noch vollständig konfigurierbar sein (z.B. brauch ich den Overhead von Portabilität ja/nein), denn es gibt ja leider nicht die "one size fits all"-Anforderungsliste für GUIs. Die Java-Leute haben sich mit Swing soviel Mühe gegeben und sind letztlich trotzdem gescheitert. Ich denke nicht, dass die C++ Leute hier besser wären.
-
HumeSikkins schrieb:
Ich denke nicht, dass die C++ Leute hier besser wären.
vorallem wenn man ewig auf aenderungen warten muss. gerade bei GUIs kann sich schnell viel tun.
mal abgesehen dass man immer das problem haben wird, dass die lib entweder zu high level ist und man nicht an das unterliegende OS kommt oder zu low level, so dass man sie sowieso wrappen muss.
-
HumeSikkins schrieb:
Threads können nicht allein auf Bibliotheksebene integriert werden. Die Sprache muss schon ein Thread-Konzept kennen bzw. definieren.
100% Zustimmung. Wenn das in C++0x nicht kommt... dann wird C++ auf Dauer für die Anwendungsentwicklung immer uninteressanter werden.
Den Punkt verstehe ich nicht. Es ist ja nicht so, dass ein C++ Programmierer als selbst programmieren muss, was nicht in der Standardlib enthalten ist. Es gibt einen riesigen Markt von C++ Bibliotheken. In allen Geschmacksrichtungen. Von akademisch über frei bis kommerziell bzw. professionell.
Dieser dezentrale Ansatz hat imo auch seine Vorteile.Hmmmm. Ich sehe keinen Vorteil darin, ein BigInteger nicht in der stdlib anzubieten. Es gibt Sachen, die will ich einfach haben, weil sie grundlegend sind, in puren C++ selber implementiert werden können und ich einfach froh bin, wenn ich nach sowas nicht erst suchen muss. Du könntest ja mal ein paar Vorteile aufzählen? Oder gilt das deiner Meinung nach nur für bestimmte libs, z.B. Networking?
Ein anderes wichtiges Thema ist imo (optionale) GC. Und zwar mit sauberer Trennung zwischen Memory- und Ressourcemanagement, also ohne das auf Destruktoren verzichtet werden muss. GC ist ja auch im Zusammenhang mit Threads ein Bonus (siehe Lock-Free-Programming).
Das Problem ist, dass z.B. in Java und C# alles so schön zusammen passt. Der GC ist cool bei Multithreading, Objektserialisierung ist bei jeglichem I/O cool, insbesondere über Sockets verschick ich oft Objekte. Die Fähigkeit, dynamisch Klassen hinzuzuladen rockt im Zusammenhang mit Reflection. Das Zeugs passt alles so gut ineinander und wenn jetzt C++ nur Reflection allein bekäme, wäre damit IMHO nicht so viel gewonnnen.
Was die Destruktoren angeht, finde ich, hast du Recht. Letztlich ist so ein finally-Block nicht so schön wie ein einfacher auto_ptr. Das ist etwas, was mich an C++/CLI sehr reizt. In C# gibts dafür ein komisches using, das muss ich mir mal ansehen.Es ist mir z.B. ein Rätsel wozu man eine Gui-Standardlib braucht. Nicht nur das so eine Lib imo ein Monsterding wäre, sie müsste auch am Besten noch vollständig konfigurierbar sein (z.B. brauch ich den Overhead von Portabilität ja/nein), denn es gibt ja leider nicht die "one size fits all"-Anforderungsliste für GUIs. Die Java-Leute haben sich mit Swing soviel Mühe gegeben und sind letztlich trotzdem gescheitert. Ich denke nicht, dass die C++ Leute hier besser wären.
Ich finde nicht, dass Swing gescheitert ist. Es ist de fakto die Standard GUI-Lib für Java und inzwischen IMHO vollkommen benutzbar. Auch das Windows Look & Feel sieht inzwischen total gut aus, hat lediglich noch ein paar kleinere Bugs, an denen man erkennen kann, dass es nicht native ist. Aber auf einen Blick sieht man das auf keinen Fall mehr. Sieh dir doch z.B. mal die NetBeans IDE für Windows an, da muss man schon nen sehr genauen Blick drauf werfen.
Wenn Swing demnächst noch OpenGL-beschleunigt wird, ist auch das Performance-Thema endgültig gegessen, obwohl es IMHO für heutige Rechner eh schon völlig passt.
Außerdem vermisse ich in der C++ lib viel elementarere Dinge als GUIs.
-
Optimizer schrieb:
Ich finde nicht, dass Swing gescheitert ist. Es ist de fakto die Standard GUI-Lib für Java und inzwischen IMHO vollkommen benutzbar. Auch das Windows Look & Feel sieht inzwischen total gut aus,
Das ist das fiese daran. es sieht fast native aus, verhaelt sich aber nicht so... das ist ein usability albtraum...
das problem mit einem standard ist: du bist fest gebunden fuer jahrezehnte daran. java kann einfach ein interface deprecaten und in 3 jahren ist es weg. passt. bei standards geht das nicht... deshalb sind viele kleinere sachen nicht sinnvoll in einer standardisierung.
biginteger hat den nachteil, dass es jeder vendor neu implementiert - wozu? da geht viel leistung verloren. da nimmt man gmp, dass ist ja quasi standard und gut ist.
natuerlich waere es super, wenn boost mehr als nur 'high end c++' waere, sondern eben auch gmp wrapper und die ganzen anderen sachen die man taeglich so braucht anbieten wuerde. das wuerde die bemuehungen zentralisieren und man haette eine extended c++ standard library die es mit jfc locker aufnehmen kann.
-
Shade Of Mine schrieb:
Optimizer schrieb:
Ich finde nicht, dass Swing gescheitert ist. Es ist de fakto die Standard GUI-Lib für Java und inzwischen IMHO vollkommen benutzbar. Auch das Windows Look & Feel sieht inzwischen total gut aus,
Das ist das fiese daran. es sieht fast native aus, verhaelt sich aber nicht so... das ist ein usability albtraum...
Ich sehe es mit jeder Version besser werden. Unter Java 5.0 fallen mir nur noch kleinere Bugs auf, der größte Teil ist IMHO voll ok.
das problem mit einem standard ist: du bist fest gebunden fuer jahrezehnte daran. java kann einfach ein interface deprecaten und in 3 jahren ist es weg. passt. bei standards geht das nicht...
Ich weiß bisher noch von keinem deprectatetem Interface/Klasse, was verschwunden ist. Java ist total abwärtskompatibel. Es ist doch eine Designfrage. Natürlich kann man ohne Probleme Swing standardisieren, weniger intelligent wäre es natürlich, dass Windows Look & Feel zu standardisieren, das muss man ja up to date halten.
Aber jetzt lass ma einfach mal die GUI.
Das ist ja gar nicht das, was ich in der C++ lib primär vermisse.biginteger hat den nachteil, dass es jeder vendor neu implementiert - wozu? da geht viel leistung verloren. da nimmt man gmp, dass ist ja quasi standard und gut ist.
Das überzeugt mich jetzt aber echt nicht. Das kann mir so egal sein, ob das Teil 50mal implementiert wird, so lange ich es nicht tun muss (oder suchen muss). Außerdem kann man wie bei Java eine Referenzimplementierung vorgeben, dann ist eine Neuimplementierung optional.
-
HumeSikkins schrieb:
Threads können nicht allein auf Bibliotheksebene integriert werden.
Genausowenig können Threads nur auf Sprachebene definiert werden. Das Betriebssystem muss die Funktionalität zur Verfügung stellen. Man kann wohl davon ausgehen, dass die meisten neueren Systeme das tun, und da Projekte wie ELKS wohl eher eine nette Spielerei als eine ernstzunehmende Anwendung sind, könnte man ein grundsätzliches Multithreading-Konzept wohl auch in die Sprache integrieren. Das heißt, man könnte es, wenn sich alle an die gegebenen Betriebssystemstandards hielten oder sich meinetwegen auch auf einen neuen einigten. Solange allerdings Microsoft an seinem eigenen Süppchen kocht und alle anderen sich an POSIX halten, dürfte ein komplexeres Konzept als in boost.thread nicht ohne eine weitere virtuelle Maschine portabel umsetzbar sein. Und so sehr ich boost.thread auch mag, es gibt eine ganze Reihe von Dingen, die es nicht kann. Es ist ein nettes Konzept und einfach anwendbar, aber für einen Sprachstandard imho nicht ausreichend.
Ein einheitliches Thread-Interface wäre eine gute Idee. Aber zuerst an der Sprache anzusetzen heißt, das Pferd von hinten aufzuzäumen. Ein Schritt nach dem anderen.
-
Optimizer schrieb:
Unter Java 5.0 fallen mir nur noch kleinere Bugs auf, der größte Teil ist IMHO voll ok.
Mir fallen genug auf. Aber man bedenke: wie lange gibt es Swing jetzt schon? Und jetzt wird es erst langsam benutzbar. denn bedenke: jeder noch so kleine bug ist eine katastrophe.
wenn es nicht native aussieht, muss es sich nicht native verhalten - aber wenn es behauptet native zu sein, ist jeder bug fatal (weil ich ja nichtmal drumherum arbeiten kann, weil ich als user ja vorher nicht weiß ob es java ist oder nicht).
Ich weiß bisher noch von keinem deprectatetem Interface/Klasse, was verschwunden ist. Java ist total abwärtskompatibel.
Und jetzt schau dir die Erweiterungen seit Java 1.0 an. stell dir mal vor, dass wäre nicht möglich gewesen und du würdest heute noch die Java 1.0 API verwenden...
Das überzeugt mich jetzt aber echt nicht. Das kann mir so egal sein, ob das Teil 50mal implementiert wird, so lange ich es nicht tun muss (oder suchen muss).
Passt doch, musst du jetzt ja auch nicht.
-
0xdeadbeef schrieb:
Das heißt, man könnte es, wenn sich alle an die gegebenen Betriebssystemstandards hielten oder sich meinetwegen auch auf einen neuen einigten. Solange allerdings Microsoft an seinem eigenen Süppchen kocht und alle anderen sich an POSIX halten, dürfte ein komplexeres Konzept als in boost.thread nicht ohne eine weitere virtuelle Maschine portabel umsetzbar sein.
es geht aber nicht nur um m$ und posix. eigentlich sämtliche multitasking-systeme (cmx, embos, ecos usw.) haben eigene proprietäre implementierungen von multitasking. zwar kennen alle gewisse mechanmismen (threadsynchronisation, datenaustausch etc. haben alle wohl die selben lehrbücher gelesen
) aber die unterschiede im einzelnen sind teilweise doch recht gross. alle haben eigene c-apis und warum sollte c++ multithreading können d.h den kleinsten gemeinsammen nenner beherrschen?
-
@0xdeadbeef
Soweit ich weiß wollen die C++ Leute im Punkte Threads einen Schritt weiterkommen. MT gibt es jetzt schon seit Jahrzenten, trotzdem hängt man bei den Abstraktionsmitteln immer noch bei low-level-Konzepten wie Mutexen oder hui Monitoren (zumindest in den aller Welt Sprachen wie Java und C#). Adas Rendevouz-Konzept ist nach wie vor noch das höchste der Gefühle.
Hier braucht's eine wirkliche Weiterentwicklung. Ob die C++ Leute da was schaffen, keine Ahnung. Cool wäre es aber.
-
Shade Of Mine schrieb:
wenn es nicht native aussieht, muss es sich nicht native verhalten - aber wenn es behauptet native zu sein, ist jeder bug fatal (weil ich ja nichtmal drumherum arbeiten kann, weil ich als user ja vorher nicht weiß ob es java ist oder nicht).
Swing muss ja auch nicht nativ aussehen, das kann man sich alles schön einstellen. Das kann sogar der Endanwender einstellen, das muss nicht mal hardgecodet sein. Du persönlich magst natürlich native GUIs. Ich auch.
Mit Swing sind Sachen möglich, die es sonst nicht gibt. Die rumzeichnerei hat seine Vorteile. Ich hab ne nativ aussehende GUI, aber mit Verbesserungen, so dass ich auch nen Button in ne Table Cell tun kann (als Beispiel). Dafür nehme ich auch erstmal minimale Bugs in Kauf, die aber wirklich schon gut gefixed sind. Mich stören sie ja auch, aber es ist nicht trivial, eine plattformübergreifende GUI-Lib zu schaffen. GTK schaut einfach nur schlecht aus, obwohl es die nativen Widgets benutzt, AWT auch. Ich kann es mir nicht ganz erklären, warum es so ist, aber scheinbar ist sowas auch nicht die Lösung.
-
Optimizer schrieb:
Ich hab ne nativ aussehende GUI, aber mit Verbesserungen
Was zwar hübsch aussieht, aber eine usability katastrophe ist.
