Nächster C++ Standard in 2009?
-
Gregor@Home schrieb:
Artchi schrieb:
Gleichzeitig sagt er aber, das der einzige Hacken zur Zeit ist, das man keine allgemeingültige GUI-Lib designen kann, die allen Platformen gerecht wird. Weil das nur wieder der kleinste gemeinsame Nenner werden würde. Und nicht weil C++ auch auf einem Toaster laufen können soll, wie viele immer behaupten.
Genau das ist das Toaster-Argument. Man will allen Plattformen gerecht werden und nur das Minimum aller Plattformen als Grundlage für die Standardbibliothek nehmen.
Wenn eine Plattform für die GUI eine Komponente oder so nicht anbietet, könnte man doch einfach von der jeweiligen Realisierung der Standardbibliothek verlangen, dass die das selbst macht. Wer irgendwas plattformspezifisches machen will, kann dann ja immer noch eine externe Bibliothek nutzen.
Nein, ebend nicht. Ich entwickel seit 5 Jahren mit Java Client-Anwendungen, und jedesmal fragen mich die Benutzer und Kunden "Warum ist das nicht so wie ich es von Windows her kenne?" "warum ist dieses Häckschen nicht grau, obwohl das Menuitem grau ist?" Andauernd bekommen wir einfachste Unterschiede, die in Swing normal sind, an den Kopf geworfen. Und wir dürfen einen Workaround programmieren -> nervig!
Ich bin Profi, mich stört es nicht wenn mal eine GUI etwas anders aussieht oder sich anders verhält. Aber die DAUs, die sich Dipl.-Ingeneure nennen, und unsere JavaClients benutzen, raffen das nicht. Und DAS würde C++ nicht viel helfen, wenn die GUI-Lib nicht alle Features eines GUIs unterstützt.
Was ist z.B. mit MacOS? Die haben doch serienmäßig nur eine Mousetaste (ich weiß, es gibt auch andere). Aber wie designe ich das in der Library? Soll ich mich an den Mac orientieren? Dann meckern die Windows-User, das sie keine 2. oder 3. Taste benutzen können. Ist in der Lib support für 3. Taste da, werden sich die Mac-User aufregen, wenn ich mein Programm darauf compiliert habe.
-
Walli schrieb:
DER Grund C++ zu nutzen ist im Moment doch nur die breite Codebasis die vorhanden ist und der Mangel an etablierten besseren Sprachen. Vom Standardkommitee wird man in der Hinsicht GUI nicht viel erwarten können. Die sind eben zu langsam, aber durch die große Verbreitung von C++ hat man auch ohne Standard alles was man braucht, wenn auch nicht aus einer Hand.
Also ich pers. benutze C++ nicht wegen der großen Code-Basis, sondern weil es mir Sprach-Features bietet, die ich woanders vermissen. Ich hab mir an den Kopf gefasst, als im Java-Spektrum-Magazin das Tool CaesarJ vorgestellt wurde. Wie toll man damit viele Wartungsprobs umgehen kann und viel flexibler wird. Am Ende stellt sich, nach dem studieren des CaesarJ-Docs, haraus, das CaesarJ Mehrfachvererbung für Java anbietet, in dem es einen Pre-Compiler (ich nenne es jetzt mal so) anbietet. D.h. CaesarJ ist einfach eine Art Java-Sprach-Extension, die die Sprach-Defizite ggü. C++ kompensiert.
So wie Bjarne Stroustrup so schön gesagt hat: was stört die Leute an den vielen C++ Sprachfeatures? Keiner muß sie benutzen, aber wenn sie mal gebraucht werden, kann man sie einsetzen.
Bei Java wiederrum mag ich, das ich gleich eine umfangreiche Library habe. Auch wenn sie nicht perfekt ist. Aber ich kann gleich loslegen und muß nicht groß Libs suchen und einrichten.
Wie gesagt, das ISO Kommittee wünscht sich für den TR2 z.B. eine Network- und XML-Libarary. Ich finde, das ist doch mal eine Aussage!
Nur muß das die C++ Community machen, das Kommittee hört sich die Vorschläge nur an und stimmt dann darüber ab, ob der Vorschlag aufgenommen wird.
-
Dafür haben sie doch - das solltest du doch eigentlich kennen - die Look&Feels eingebaut in Java Swing eingebaut. Wenn du natürlich die Java-Oberfläche statt Windows-Native verwendest wird das Häkchen nicht grau
MfG SideWinder
-
Also ich habe natürlich Windows-L&F, und das Häckchen ist nicht grau. Kann sein das es in Java 1.5+ behoben wurde, in 1.4 ist es einer von vielen Defiziten. Woebei das mit dem Häckchen eines von vielen Beispielen ist.
Wo sind z.B. die Popups-Menus für die Eingabefelder? (gehört auch zum Look&Feel!) Darf ich auch selber proggen oder mir im Netz eine Lib suchen. Wenn ich alle Defizite aufzählen würde, könte ich ein Buch schreiben.
-
Was spricht gegen JPopupMenu? Naja verlieren wir uns nicht in den Details, Java 1.4.x ist sowieso seit über einem Jahr nicht mehr Stand der Technik. Das sind zudem nicht alleine javaspezifische Probleme, du wirst ähnliche Probleme mit QT und anderen plattformübergreifenden GUI-Libraries haben.
MfG SideWinder
-
SideWinder schrieb:
Was spricht gegen JPopupMenu?
Ja, hab ich gesagt: selber machen oder lib suchen. Aber warum hat Javas JTextfield kein Popup mit Cut, Copy & Paste???????? Ich muß jedem User sagen, das er mit Strg+V einen Text einfügen kann, wenn ich mal wieder einen Anruf erhalte. Das ist doch der Witz an der Sache, den Bjarne Stroustrup meint!
Naja verlieren wir uns nicht in den Details, Java 1.4.x ist sowieso seit über einem Jahr nicht mehr Stand der Technik.
Ja, wir konnten leider noch nicht auf 1.5 umsteigen, weil uns unsere Anwendung manchmal unter 1.5 einfriert.
Unter 1.4 läufts soweit. Müssen erstmal den Bug finden. Egal...Das sind zudem nicht alleine javaspezifische Probleme, du wirst ähnliche Probleme mit QT und anderen plattformübergreifenden GUI-Libraries haben.
Jetzt hast du haargenau das gesagt, was Bjarne auch sagt. Die allgemeingültigen Libs haben solche Probs, und unter C++ wäre es nicht anders. Genau das will man nicht. Weil am Ende eh jeder z.B. in seiner Windows-Applikation z.B. MFC benutzen würde, wenn er nicht gerade platformunabhängig sein braucht.
-
Artchi schrieb:
Also ich habe natürlich Windows-L&F, und das Häckchen ist nicht grau. Kann sein das es in Java 1.5+ behoben wurde, in 1.4 ist es einer von vielen Defiziten. Woebei das mit dem Häckchen eines von vielen Beispielen ist.
Wo sind z.B. die Popups-Menus für die Eingabefelder? (gehört auch zum Look&Feel!) Darf ich auch selber proggen oder mir im Netz eine Lib suchen. Wenn ich alle Defizite aufzählen würde, könte ich ein Buch schreiben.
Ich sehe das Problem da so. Da versucht man, wie etwas anderes auszusehen und schafft das nicht bis in alle Details. Das fällt den Leuten dann auf. Die Lösung ist einfach. Nutze eben NICHT das Windows L&F. Dann ist von Anfang an klar, dass das in dem Programm anders ist. Unter Windows haben ja auch eine ganze Menge Programme ein individuelles Aussehen und es macht keinem etwas aus. Insofern sehe ich da kein Problem.
-
@Gregor: Das wäre ein Schritt in die falsche Richtung. Wenn Windows etwas geschafft hat, dann ein einheitliches Fenster-Format. Anwendungen die dauernd ihr eigenes Süppchen kochen kann ich nicht ausstehen. Das fängt bei der Belegung von Shortcuts an und hört nicht zuletzt beim Popup-Menü vom Edit-Feld auf.
Weil am Ende eh jeder z.B. in seiner Windows-Applikation z.B. MFC benutzen würde, wenn er nicht gerade platformunabhängig sein braucht.
Jop, und bevor man selbst auch noch eine Library hinuzfügt, die dann nur eine von vielen mit dem Ziel den Rest zu erstzen ist, baut man am Besten gar keine.
Ja, wir konnten leider noch nicht auf 1.5 umsteigen, weil uns unsere Anwendung manchmal unter 1.5 einfriert.
MfG SideWinder
-
Artchi schrieb:
Walli schrieb:
DER Grund C++ zu nutzen ist im Moment doch nur die breite Codebasis die vorhanden ist und der Mangel an etablierten besseren Sprachen. Vom Standardkommitee wird man in der Hinsicht GUI nicht viel erwarten können. Die sind eben zu langsam, aber durch die große Verbreitung von C++ hat man auch ohne Standard alles was man braucht, wenn auch nicht aus einer Hand.
Also ich pers. benutze C++ nicht wegen der großen Code-Basis, sondern weil es mir Sprach-Features bietet, die ich woanders vermissen.
Den Teil mit "und der Mangel an etablierten besseren Sprachen" hast du überlesen, oder?
-
@Walli! Ob du es glaubst oder nicht, hab ich tatsächlich nihct registriert. Sorry!
Dann nimm mein Antwort-Posting als Ergänzung auf.
-
C++ ist wirklich eine geniale Sprache, von den Möglichkeiten und der Performance. Aber der Standard ist einfach nur *hust*. Die Methodennamen sind oft nicht gut gewählt, Standardausgabe mittels cout ist alles andere als effektiv und die string Klasse ist auch nicht das Gelbe vom Ei.
Boost ist schon ein guter Ansatz, Qt zeigt auch wie man etwas machen könnte. Was jetzt nocht fehlt, wäre ein Projekt ähnlich Boost welches eine Art C++ Desktop Umgebung bildet. Mit den derzeitigen Möglichkeiten und der Geschwindigkeit des neuen Standards wird C++ gegenüber Java und C# immer weiter an Boden verlieren.
BTW: Ich meine mal gelesen zu haben, dass Volkard an einer Reimplementierung von cout arbeitet? Das wär ja schon mal ein Anfang
-
-Marc- schrieb:
...
Mit den derzeitigen Möglichkeiten und der Geschwindigkeit des neuen Standards wird C++ gegenüber Java und C# immer weiter an Boden verlieren.
...Behauptung, oder?
Abwarten wie es sich entwickeln wird.
mfg
v R
-
Habe hier mal ein Interview mit den Erfindern von C, C++ und Java gefunden. Sehr interessant, was z.B. Bjarne zum Standard sagt und was der Java Erfinder James Gosling sagt:
Q: Is it important to have a formal (e.g., ISO/ANSI) standard for a programming language? What are the advantages? The disadvantages?
Stroustrup: In today's overheated commercial atmosphere it is essential to have a formal standard. Without a formal standard, there is no defense against rapacious vendors. Naturally, an ISO standard is not a complete defense, and not all of our languages, libraries, or tools can be standardized. However, without a standard, users are completely at the mercy/whim of their suppliers.
The major advantage is to have a standard that isn't manipulated to serve the commercial interests of a company or a small group of companies. An ISO standard emerges from a consensus process that gives voice to individuals, companies, and nations.
The major disadvantages are that the essential consensus building takes time, that the committee has limited resources, and that it is hard to create a consensus for something innovative. However, it can be done: Remember the STL.
Gosling: I think it would be a nice thing to have a formal standard. I think most people have a very naive view of what a formal standard is. Fundamentally the standards bodies that create formal standards are places to store documents that have stamps on them. They don't have any notion of conformance testing. To be an ANSI standard C compiler, all you have to do is say that you're an ANSI standard C compiler; there's absolutely no testing of that at all. The hard part for me about formal standards is that, to an extent that most people are completely unaware of, the formal standards process is intensely political. We've made a couple of runs at turning Java into a formal standard, and the politics got so absurd that it became impossible in both cases.
Stroustrup: Conformance suites are widely used for ISO C and ISO C++.
Quelle: http://www.gotw.ca/publications/c_family_interview.htm
Sehr interessant, das Sun bereits mehrmals versucht hat ihr Java als ISO Standard durch zusetzen. Und kläglich gescheitert ist.
Jetzt kommt der Knüller:
Q: What have you learned from going through a standards effort for [C/C++/Java]?
Stroustrup: Consensus building is tedious and necessary. People and organizations really do want to do "the right thing" given half a chance. Political problems cannot be solved. The way you handle a political problem is to find the technical problem at its root and solve that instead. Then, the political problem will evaporate.
Gosling: It's mostly been a political education that I would rather not have ever had, thank you.
Leicht zerschlagen der Typ, wie?
Aaaaaalso, ich finde dafür das es anscheinend wirklich ein Kraftakt zu sein scheint, wir trotzdem C++98 erhalten haben und trotz allem C++0x in arbeit ist, trotz des Stesses... sollten wir wohl Respekt vor dem C++ Standard Kommittee und ihrer Arbeit zeigen! Und hoffen das wir bald C++0x im ISO sehen können.
-
*rofl* De Java-Typ is plemplem^^ Die kriegen doch nur den Standard nicht, weil Sun die Rechte an "Java" nicht hergeben will. Das wäre aber nötig, wenn es ein ISO-Standard werden soll ... .
-
Pellaeon schrieb:
*rofl* De Java-Typ is plemplem^^ Die kriegen doch nur den Standard nicht, weil Sun die Rechte an "Java" nicht hergeben will. Das wäre aber nötig, wenn es ein ISO-Standard werden soll ... .
Sun hat leider die Erfahrung machen müssen, dass es sehr wichtig ist, diese Rechte zu haben. Sonst kann man inkompatiblen Versionen nichts entgegenhalten. Die "JVM" von Microsoft hätte so nicht bekämpft werden können und das hätte möglicherweise dazu geführt, dass Java zerfallen wäre. C++ hatte doch lange Zeit ganz ähnliche Probleme: Wie lange hat man C++-Compiler genutzt, die alles andere als standardkonform waren? Da konnte man sich als Programmierer nicht an irgendeinen Standard halten, sondern musste immer ganz genau gucken, mit was der eigene Code eigentlich kompiliert. Auch beim nächsten C++ Standard wird es sicherlich wieder so sein, dass man sich lange Zeit nicht sicher sein kann, wo was läuft.
Und wir wollen doch eins festhalten: Java ist zwar nicht bei einer Standardisierungsorganisation wie der ISO standardisiert, ist aber trotzdem ein offener Standard. Jeder kann die Sprachspezifikation runterladen und kann sich seine eigene JVM und Standardbibliothek bauen. Das ist nicht irgendwie ein Industriegeheimnis oder so. Sun kommt da erst ins Spiel, wenn die eigene Version auch den Namen "Java" tragen soll. Insofern sehe ich da gar keinen Kritikpunkt an Java. Mir kommt es eher so vor, dass der Standardisierungsprozess von C++ hier durch die rosarote Brille gesehen wird. Aus meiner Sicht bietet er aber weiterhin überhaupt keine Vorteile. Er ist lahm, bringt kein homogenes Ergebnis und der Standard kann nicht verteidigt werden.
Als Kritik am Entwicklungsmodell von Java höre ich meistens nur "Was ist, wenn Sun pleite geht?" oder "Was ist, wenn Sun plötzlich Geld haben will?". Ich bitte euch: Solche Gedankenspiele gehen sowas von an der Realität vorbei, da kann man sich nur wundern, dass Leute so argumentieren.
-
Kann sein dass mir der Standardisierungsprozess net ganz geläufig ist, aber gerade bei Java wo Sund ja eh die Sprache kontrolliert, müssts doch einfacher sein aus einem festen Stand(von mir aus die aktuelle Version) den Standard zu machen. Oder denk ich da ganz falsch?
-
Im Übrigen finde ich nichts schlimmes daran, dass Java von Sun gehandelt wird, ich mag die Jungs bei Sun. Bei C# ist ja auch keiner angepisst, nur weil MS dahinterteckt, oder? Weiß nicht, aber mir sind jetzt keine Fehlentscheidungen von Sun bzgl. Java bekannt, die durch einen ISO - Standard hätten vermieden werden können...
-
Talla schrieb:
Kann sein dass mir der Standardisierungsprozess net ganz geläufig ist, aber gerade bei Java wo Sund ja eh die Sprache kontrolliert, müssts doch einfacher sein aus einem festen Stand(von mir aus die aktuelle Version) den Standard zu machen. Oder denk ich da ganz falsch?
Sieh doch einfach folgendes als "Standard" an:
1. Java Language Specification
2. Java Virtual Machine Specification
3. Java API SpezifikationenWas willst du mehr?
-
GPC schrieb:
Weiß nicht, aber mir sind jetzt keine Fehlentscheidungen von Sun bzgl. Java bekannt, die durch einen ISO - Standard hätten vermieden werden können...
Hab da eines aus der Praxis: Wir haben hier ApplicationServer (WebSphere) von IBM auf Solaris-Maschinen laufen... natürlich alles mit J2EE-Zertifikat. So, alles schön per RMI, so wie es von Sun propagiert wird. So nach dem Motto, vergesst CORBA, RMI und Java sind cooler. OK... So, Java-Clients sind Java 1.3 gewesen. Gut, haben wir uns gedacht, steigen wir doch mal zumindest mit den Clients auf Java 1.4 um, Server können ja erstmal weiter auf 1.3 laufen (kannst ja nicht in einem Welt-Konzern wie Volksw*** so ebend mal über Nacht auf neue Server-Versionen migrieren).
Wir erste Tests mit Java1.4-Runtimes auf den Clients ausprobiert... AUTSCH! Das hätte man nicht tun dürfen!
Java 1.4 und Java 1.3 sind über RMI binär inkompatibel. Nix ging! Gut... macht nichts, können wir halt die Clients erstmal nicht auf 1.4 laufen lassen.So, toller Standard, wenn Sun einfach das binäre serielle Format von einer Java Version auf die andere ändert. Vorallem in Enterprise-Umgebungen.
Jetzt machen wir alles über SOAP, weiß zwar nicht warum wir dann noch Java benutzen, könnten ja auch .NET mit C# nehmen oder gar C++.
Die Migration der ganzen J2EE-Applikationen auf Java 1.4-Server macht IBM jetzt erstmal bis zum nächsten Jahr kostenlos, weil keiner das sonst bezahlen will, abe IBM natürlich seine neuen AppServer hier verticken will.
Ja, die tolle Java-Welt...
-
GPC schrieb:
Bei C# ist ja auch keiner angepisst, nur weil MS dahinterteckt, oder?
Im Gegensatz zu Java ist aber C# immerhin von MS für den ECMA-Standard frei gegeben worden. Genauso wie das Basis-.NET-Framework.