Nächster C++ Standard in 2009?
-
volkard schrieb:
einen elegantern ausweg sah ich mal in frankfurt in nem unternehmen. chef kaufte kaffemaschine für 1200DM, wo man nur auf einen knopf drücken mußte und fertiger kaffe kam raus. das einzige, was noch an warung anfiel war, hin und wieder frischen kaffe einzufüllen und alten kaffe wegzuwerfen. und ich habe keine ahnung, wer das machte.
Ja, das ist prima. So ein Teil steht in der Firma, in der ich gelgegentlich arbeite, auf jeder Etage. Sehr praktisch. Nachfüllen wird vom Kantinen-Personal gemacht. Nur manchmal muß man den Trester leeren... da wird dann immer ausprobiert, wie lange die Maschine trotz Warnung doch noch Kaffee produziert.
-
@phlox
C++ arbeitet nach einem anderen Ansatz, als .NET oder Java. Auch 09 werden die nicht alles drin haben, was man für die C++ Programmierung braucht. Aber C++ wollte auch nie alles abdecken (oder willst du mir erzählen, dass die 98 nicht mit dem Erfolg von grafischen GUIs gerechnet hätten).huh? schrieb:
hab ich was verpasst? wird die programmiersprache C++ nun auf C++0x umbenannt oder heisst der neue standard dann einfach C++0x wie er heute IEC:14882 heisst?
Nein, C++ wird weiter C++ heißen. Das man das Jahr an die Programmiersprache hängt, um den Unterschied zwischen den Standards deutlich zu machen ist schon älter. Siehe Algol68 oä. Der Standard wird natürlich auch eine eigene ISO/IEC Nummer bekommen. C++09 (wenn er denn 2009 kommt), ist dann die umgangssprachliche Bezeichnung
-
C++ will nicht anders sein als Java oder .NET. Lies mal die Wunschliste des C++ Kommittees durch. Selbst Bjarne Stroustrup hat offiziell einen Eintrag getätigt, in dem er sich endlich für den C++ Standard eine GUI-Lib wünscht. 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. Es ist also einfach nur ein Problem, es nicht jedem Recht machen zu können, da GUIs auf jeder Platform verschiedene Features haben.
-
Das mit der GUI Lib ist doch einfach illusorisch. Natürlich würde das C++ Komitee gerne alles anbieten. Aber du sagst ja selbst, dass die wissen, dass dies nicht funktioniert.
C++ ist eben doch anders als Java oder .NET. Java und .NET haben zB. viel freiere Update Zyklen. Da ist es leichter zu reagieren und die libraries oder Sprache anzupassen (siehe .NET 2.0). C++ hat das eben nicht, stellt einem dafür aber ein solides Grundgerüst zur Verfügung. Wer mehr will, kauft sich eben ein Framework ala QT oä.
-
Die Update-Fähigkeit hat ja wohl as Kommittee mit den TRs eingeführt. TR1 ist fertig definiert, wird wohl auch in der nächsten VC++ Version rein kommen, wenn ich die VC++-Produktchefin von MS nicht falsch verstanden habe.
Dann kommt 2009 der C++09 wohl raus. Und danach soll der TR2 rauskommen, für den bis Okt. 2006 Vorschläge angenommen werden.
D.h. die TRs werden zukünftig die Library-Updates darstellen, unabhängig von neuen C++-Standard-Releases.
-
Die Frage ist, ob das überhaupt gut ist so wie Java und C# werden zu wollen. Dann kann ich ja gleich Java oder C# nehmen...
MfG SideWinder
-
Eben. Wenn C++ auf den gleichen Zug wie Java und C# aufspringen möchte nur mit 10 Jahren Versatz, dann gibt es keinen Grund mehr C++ zu benutzen.
-
Mag sein, aber ein bisschen weniger minimalismus wäre schon schön. Ich finde es einfach blöd, für alles was außerhalb von I/O, Containern und Standardalgorithmen liegt, ne extra lib nehmen zu müssen, auch wenn boost sehr viel abdeckt. Deshalb muss man ja nicht gleich wie Java oder C# werden.
-
C# und Java sind eindeutig für den Plattform-Markt ausgelegt, TCP/IP-Sockets machen Sinn.
C++ hingegen hat für mich immer den Vorteil gehabt viel breiter zu sein. Warum also gerade TCP/IP-Sockets, nein wenn dann protokollunabhängige Sockets. Das wiederrum führt zu einer zu aufgeblähten Library die dann erst recht nieamnd mehr benutzen will wenn er nur TCP/IP benötigt. Letzten Endes landet man wieder wo man vorher war.
MfG SideWinder
-
Walli schrieb:
Eben. Wenn C++ auf den gleichen Zug wie Java und C# aufspringen möchte nur mit 10 Jahren Versatz, dann gibt es keinen Grund mehr C++ zu benutzen.
Das hört sich ja fast so an, als ob das Fehlen von vielen Dingen in der Standardbibliothek ein Pluspunkt für C++ ist. "Ein Grund, warum man C++ nutzt". Das muss man doch andersherum sehen. IMHO ist das momentan ein Grund, C++ nicht zu nutzen. Wenn C++ das beheben würde, dann würde es gegenüber .NET oder auch Java eine Schwachstelle beheben. ...und da sage ich "Besser spät als nie".
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.
-
Das hört sich ja fast so an, als ob das Fehlen von vielen Dingen in der Standardbibliothek ein Pluspunkt für C++ ist.
Assembler fehlt keine Socket-Library. C++ fehlt keine GUI-Library. Java fehlt keine Library für Satellitensteuerung. Ja ich sehe es als Pluspunkt das ich hier die freie Wahl habe.
MfG SideWinder
-
Was ist eignentlich so schlimm daran eine Biblotek zu nutzen? Es ist ja nicht so als wenn platformunabhänglige GUI Entwickelung nur in Java möglich wäre.
-
Gregor@Home schrieb:
Walli schrieb:
Eben. Wenn C++ auf den gleichen Zug wie Java und C# aufspringen möchte nur mit 10 Jahren Versatz, dann gibt es keinen Grund mehr C++ zu benutzen.
Das hört sich ja fast so an, als ob das Fehlen von vielen Dingen in der Standardbibliothek ein Pluspunkt für C++ ist. "Ein Grund, warum man C++ nutzt". Das muss man doch andersherum sehen. IMHO ist das momentan ein Grund, C++ nicht zu nutzen. Wenn C++ das beheben würde, dann würde es gegenüber .NET oder auch Java eine Schwachstelle beheben. ...und da sage ich "Besser spät als nie".
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.
-
SideWinder schrieb:
Das hört sich ja fast so an, als ob das Fehlen von vielen Dingen in der Standardbibliothek ein Pluspunkt für C++ ist.
Assembler fehlt keine Socket-Library. C++ fehlt keine GUI-Library. Java fehlt keine Library für Satellitensteuerung. Ja ich sehe es als Pluspunkt das ich hier die freie Wahl habe.
MfG SideWinder
Nun gut, aber dann stellen sich mir folgende Fragen:
1. In welche Richtung soll sich C++, dem Wunsch des ISO Komitees nach, dann entwickeln?
2. Welche Auswirkungen hat das auf C++ (besonders auf Einsatzgebiet und Verbreitung), wenn die Standardlib nicht auf dem Niveau von Java ist bzw. einfach mal ein paar wichtige Features reinkriegt?EDIT: Rechtschreibfehler korrigiert
-
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.