Nächster C++ Standard in 2009?
-
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.
-
hm das war erstmal weder positiv noch negatiov gemeint: es ist einfach ein Fakt, dass Sun die Rechte behalten will und daher kein ISO-Standard für Java möglich ist. Daher ist dieser "Politik-Rotz" in dem Zitat, dass Artchi von dem Javamann gepostet hat einfach total fehl am Platz.
Gregor@Home schrieb:
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.
Vor nicht allzu langer Zeit hat Sun rote Zahlen geschrieben. Soooooooooooooooo abwegig ist das nun nicht, klar morgen wirds nicht passieren, aber dennoch muss man sowas zumindest im Auge behalten.
Zum Thema Stanard verweis ich gern auf artchis Post vor mir
Gregor@Home schrieb:
[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.
Diese Probleme gab es VOR der Verabschiedung des Standards. Das kurz danach dann noch auf einmal "alte" Compiler im Umlauf und gebrauch sind ist klar.
Bei Java dasselbe, siehe Artchi-POst(mal wieder^^)
-
Gregor@Home schrieb:
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.
MS hat doch nur sein eigenes Java gemacht, eben weil Sun die Rechte daran hat. Hätte Sun es an ISO frei gegeben, hätte MS so verfahren wie bei C++: so weit wie möglich an den ISO-Standard ran kommen, was sie mit C++ auch gut geschafft haben.
Würde Java ein ISO-Std sein, hätten wir heute wahrscheintlich kein .NET. Und IBM würde sich nicht mit Sun streiten, Java frei zu geben (ja, komisch das auch IBM das fordert).
-
Artchi:
He he, da habt ihr ja eine ganz schöne Scheiße
Na gut, Sun hat sich das Recht vorbehalten bzw. in Anspruch genommen, die 1.4 RMI inkompatibel zur 1.3 zu gestalten, ich schätze sie hatten ihre Gründe dafür, auch wenn ihr jetzt blöd dasteht und die Suppe auslöffeln dürft. Trotzdem denke ich, dass ein, sich entwickelnder, Standard Probleme hätte, kompatibel zu bleiben. Meinst nicht?MS hat doch nur sein eigenes Java gemacht, eben weil Sun die Rechte daran hat.
Dann hätten sie aber wenigstens ein zu Sun konformes Java rausbringen können.
Btw. Es ist egal ob wir das jetzt gut finden oder nicht, es ist halt so und wir müssen auch jeden Tag damit klarkommen. That's the way it is...
-
Dann hätten sie aber wenigstens ein zu Sun konformes Java rausbringen können.
...oder auf Java statt C# setzen können. J ein Sharp zu verpassen hats nicht gebracht. Jetzt versuchen sie es mit C.
MfG SideWinder
-
Pellaeon schrieb:
Vor nicht allzu langer Zeit hat Sun rote Zahlen geschrieben. Soooooooooooooooo abwegig ist das nun nicht, klar morgen wirds nicht passieren, aber dennoch muss man sowas zumindest im Auge behalten.
[...]
Diese Probleme gab es VOR der Verabschiedung des Standards. Das kurz danach dann noch auf einmal "alte" Compiler im Umlauf und gebrauch sind ist klar.
Bei Java dasselbe, siehe Artchi-POst(mal wieder^^)1. Sun hatte die ganze Zeit liquide Mittel in der Höhe von etwa $7Mrd.. Da hätten sie noch sehr lange rote Zahlen in der Größenordnung schreiben können, bevor sie ein Problem gehabt hätten.
2. Also hier im Forum war das Problem der nicht standardkonformen Compiler zumindest so 2001 noch sehr aktuell. 3 Jahre nach dem Standard. ...ganz schön lange in der IT-Branche, heh? Kann man dann 2012 damit rechnen, dass der neue Standard, der für 2009 geplant ist, halbwegs eingehalten wird?
Artchi schrieb:
Würde Java ein ISO-Std sein, hätten wir heute wahrscheintlich kein .NET. Und IBM würde sich nicht mit Sun streiten, Java frei zu geben (ja, komisch das auch IBM das fordert).
Ja, mag schon sein, dass es dann kein .NET geben würde. Dann hätte MS die Javawelt gespalten. Es ist ja sehr schnell so, dass man die Variante von MS als "den Standard" ansieht. Ist ja bei C++ genauso. Wie oft sagt hier einer, dass er "MS-VC++" lernen will. ...und irgendwann wundert man sich dann, dass man eben nicht das gelernt hat, was man eigentlich lernen wollte, sondern stattdessen die MFC oder so als Standard angesehen hat. Ist ja bei .NET genauso: Das ist nur teilweise standardisiert. Viele wichtige Bibliotheken sind Erweiterungen von MS, aber darum kümmert sich natürlich fast keiner, der das lernt. Wenn man soetwas nicht vorher weiß, hat man es ja auch schwer, das festzustellen.