C++ next Generation
-
http://golem.de/0507/39160.html
fyi.Endlich hört man mal etwas davon
-
devil81 schrieb:
Endlich hört man mal etwas davon
Es ist nicht so, dass es nicht genügend Informationen zum Thema C++0X gibt. Du musst nur die richtigen Quellen lesen. Z.B. das CUJ oder halt comp.lang.c++.moderated und comp.std.c++.
-
HumeSikkins schrieb:
devil81 schrieb:
Endlich hört man mal etwas davon
Es ist nicht so, dass es nicht genügend Informationen zum Thema C++0X gibt. Du musst nur die richtigen Quellen lesen. Z.B. das CUJ oder halt comp.lang.c++.moderated und comp.std.c++.
naja, jetzt scheint es auch nerd-inkompatibel zu sein :p
-
Ich war schneller. :p
-
Gilt die 0 in C++0x eigentlich als gesichert?
MfG SideWinder
-
SideWinder schrieb:
Gilt die 0 in C++0x eigentlich als gesichert?
Also ich würde nicht drauf wetten
Woah: Das war mein 10000 Beitrag
Ich glaube es wird Zeit für den Ruhestand.
-
wow.. drehts jetzt um?
dann gehst von vorne los *g*
-
Ich glaube nicht, dass der neue Standard überhaupt noch rechtzeitig kommt, um mit anderen Sprachen mithalten zu können. Und wenn er da ist, ist er noch fetter und aufgeblähter als der jetzige, weil das Kommittee an jedem noch so blöden Feature festklammert (Exception Specifications, hallihallo).
Will mir nicht irgendwer Hoffnung machen, dass meine Lieblingssprache noch auf einen grünen Zweig kommt?
-
operator void schrieb:
Will mir nicht irgendwer Hoffnung machen, dass meine Lieblingssprache noch auf einen grünen Zweig kommt?
Das tut jetzt weh, aber: C++/CLI
-
Will mir nicht irgendwer Hoffnung machen, dass meine Lieblingssprache noch auf einen grünen Zweig kommt?
Also ich persönlich finde den TR1 schon sehr vielversprechend.
Meinetwegen müssten die auch nicht so furchtbar viel ändern. Die Einführung von auto als typeof-Operator, ein Konzept-Konzept, die Unterstützung von Nebenläufigkeit und vielleicht noch ein besseres Modul-Konzept und gut. Dazu noch ein paar praktische Änderungen: z.B. bessere Fehlermeldungen bei Templates.Man sollte imo nicht versuchen aus C++ eine Übersprache zu machen die selbst Managern gefällt. So eine Art .NET oder Java "on Steroids" mit riesiger Standardbibliothek (inklusiver GUI-Lib, WebServices, XML-Zeugs usw.). Lieber nur ein paar neue Abstraktionen die z.B. die generische Programmierung noch erleichtern und den Rest in die Hände der C++-Community legen.
Um auf die Frage zu kommen: wie sieht für dich der grüne Zweig denn aus? Was fehlt deiner Meinung nach am dringensten?
-
Tja, C++0x wird nicht mehr viel reissen können. Ich habe mir mal angeschaut was die sich so überlegen und diskutieren. Irgendwie wird da an den falschen Stellen gebastelt. Die Standardlib wird um Dinge erweitert, die keiner vermisst, weil es sie schon fertig gibt (regex z.b.). Aber Sockets die hier jeder vermisst, sind immer noch nicht verabschiedet (oder?). Auch wäre es mal angebracht die Lib-Dateien (also das Dateiformat) zu standardisieren, damit man mal Libs zwischen verschiedenen Compilern/Linkern benutzen kann. Man sieht ja wie sich Benutzer von Qt, Boost usw. mit den Builds ein Bein ausreissen. Anstatt das man einfach die fertigen Lib-Dateien plus Header zum Download anbietet.
Außerdem finde ich, sollten sich eher die IDE-Hersteller mal am Riemen reißen, die IDEs hinken den Java-IDEs mächtig hinterher. Ja ich weiß, Java ist nicht so komplex und hat vorallem Reflection, denen sich die IDEs mächtig bedienen. Aber trotzdem vermisse ich grundlegende Dinge in C++ IDEs die nichts mit der fehlenden Reflection zu tun haben.
-
Die Standardlib wird um Dinge erweitert, die keiner vermisst, weil es sie schon fertig gibt (regex z.b.)
Ein Domänen-unabhängiges Tool wie regex gehört imo eindeutig in die Standardlib.
Aber Sockets die hier jeder vermisst, sind immer noch nicht verabschiedet (oder?).
Dafür sehe ich z.B. überhaupt keinen Grund dafür, warum Standard-C++ Sockets enthalten muss. Es gibt einen Standard für Sockets. Und warum ausgerechnet Sockets? Warum nicht RPC oder RMI? Warum nicht gleich eine ORB-Architektur?
Auch wäre es mal angebracht die Lib-Dateien (also das Dateiformat) zu standardisieren, damit man mal Libs zwischen verschiedenen Compilern/Linkern benutzen kann.
Das liegt wohl eher außerhalb des Standards und wäre auch absolut nicht Rückwärtskompatibel.
-
HumeSikkins schrieb:
Ein Domänen-unabhängiges Tool wie regex gehört imo eindeutig in die Standardlib.
Ich hab ja nichts dagegen das es drin ist, nur fänd ich anderes wichtiger.
HumeSikkins schrieb:
Dafür sehe ich z.B. überhaupt keinen Grund dafür, warum Standard-C++ Sockets enthalten muss. Es gibt einen Standard für Sockets. Und warum ausgerechnet Sockets? Warum nicht RPC oder RMI? Warum nicht gleich eine ORB-Architektur?
Aber Sockets sehe ich als Basics an, wie die fstreams. Nach deiner Argumentation müssten auch fstreams nicht in der Std drin sein? Bin ja mal auf deine Antwort gespannt.
HumeSikkins schrieb:
Das liegt wohl eher außerhalb des Standards und wäre auch absolut nicht Rückwärtskompatibel.
Wer sagt denn, das es außerhalb des Std liegt?
Wenn im Std solche banalen Dinge drin steht wie "Jede Quellcodedatei mit mit einer Leerzeile enden." dann kann man auch ein Lib-Format in den Std schreiben. Genauso wie die Präprozessoren beschrieben sind...Die Rückwärtskompatibilität würde aber eh keinen Sinn machen, weil die Libs doch eh nicht kompatibel sind. Teilweise nicht mal in einer Compiler-Linie!!!
-
das mit den lib dateien kann überhaupt nicht funktionieren so wie du dir das vorstellst
-
Aber Sockets sehe ich als Basics an, wie die fstreams. Nach deiner Argumentation müssten auch fstreams nicht in der Std drin sein? Bin ja mal auf deine Antwort gespannt
Was soll ich dazu sagen? Wo ich doch gar keine allgemeingültige Argumentation aufgemacht habe.
Ich kann dazu nur sagen, dass eine Datei, als Strom dargstellt, schon noch etwas anderes ist als ein Socket. Eine Netzwer- bzw. Inter-Prozess-Kommunikation setzt zumindest schonmal ein Netzwerk oder mehrere parallele Prozesse voraus. Dateihandling auf der anderen Seite ist wohl die minimalste Form der Ein-/Ausgabe. Und wie man an den sehr limitierten Fähigkeiten von fstreams sieht wird selbst diese nicht im Großen Stil vom Standard unterstützt. Sobald Dateisystem-spezifische Dinge notwendig sind, muss man externe Libs verwenden. Wie willst du hingegen eine Socket-Bibltiohek spezifizieren ohne bestimmte Protokolle usw. vorzuschreiben?Und selbst wenn du dich für eine Netzwerk- bzw. IPC-Kommunikation entscheidest, warum gerade Sockets?
Wer sagt denn, das es außerhalb des Std liegt?
Das habe ich im Beitrag darüber gesagt.
Wenn im Std solche banalen Dinge drin steht wie "Jede Quellcodedatei mit mit einer Leerzeile enden."
Das ist doch nicht zu vergleichen! Gerade weil es banal ist. Auf der anderen Seite wäre die Forcierung eines Dateiformats alles andere als Banal. Welches ist das Effizienteste? Für welche Definition von Effizient? Für welche Platform? 32-bit? 64-bit LP? 64-bit LLP?
Welche Art der Debug-Informationen sind die Richtigen?Genauso wie die Präprozessoren beschrieben sind...
Wie meinen? Der Präprozessor ist genauso abstrakt spezifiziert wie der Rest der Sprache auch. Kein Mensch legt fest, wie der Präprozessor intern arbeitet. Du musst nicht mal einen Präprozessor als eigenes externes Tool haben.
Die Rückwärtskompatibilität würde aber eh keinen Sinn machen, weil die Libs doch eh nicht kompatibel sind
Es ging um die Kompatibilität der Tools. Wenn du aufeinmal ein eigenes Format spezifizierst, was passiert mit den derzeitigen Linkern?
Ich weiß aber ehrlich gesagt auch gar nicht was genau du dir vorstellst bzw. von was für Libs du sprichst.
-
Die Vorschläge für C++0x finde ich ja alle sehr schön (auto, Konzepte usw.), es geht mir auch gar nicht darum, dass mir unbedingt viel _fehlt_. Ich würde nur viel mehr mit dem Rotstift arbeiten.
Wie gesagt, Exception Specifications sind ein totaler Fehlgriff - aber sie werden wahrscheinlich Teil der Sprache bleiben, bis sie neben Cobol im Regal verstaubt.
Dito für Argument Dependent Lookup, den eigentlich nur Herb Sutter öffentlich verteidigt und der, außer für Operatoren, die Sprache IMHO nur verkompliziert. Das haben ja auch schon einige Leute eingesehen. Aber was ist die Gegenmaßnahme? Richtig: Einfach _noch_ ein Sprachkonzept einführen (explicit namespaces und was da alles vorgeschlagen wurde)! Was soll dabei rauskommen, wenn sich heute schon die wenigsten C++-Programmierer der unnötigen namespace-Tücken bewusst sind?
export templates, valarrays... Flops über Flops, aber gestrichen wird nichts. C++0x hat das Potenzial, ein völlig unübersichtlicher Mammutstandard zu werden. Und dann sollen noch große Erweiterungen per CLI/C++ dazu kommen... und währenddessen zaubern Sprachen wie C# mal eben Entwürfe für Lambdas aus dem Hut, an denen das C++-Kommittee noch ein paar Jahrzehnte knabbern wird.
-
was ich schade finde ist, dass das standardcommitee sich so sehr an altem code festklammert, anstatt einfach mal reinen Tisch zu machen.
(ja ich weis, dass die Firmen viel Geld in erstellung und wartung ihres codes investiert haben, aber wenn dadurch zukünftiger code einfacher werden würde, wär das sicher viel wert.)
-
otze schrieb:
was ich schade finde ist, dass das standardcommitee sich so sehr an altem code festklammert, anstatt einfach mal reinen Tisch zu machen.
Das ist der Grund warum C++ überhaupt soweit verbreitet ist. Hätte Stroustrup damals reinen Tisch gemacht und die hässlichen C-Narben ausgemerzt (und damit ein zu C inkompatible Sprach erschaffen), dann hätte C++ heute wahrscheinlich eine Verbreitung wie SmallTalk.
export templates, valarrays... Flops über Flops
Flops über Flops? Ich sehe hier drei Flops die alle mit den besten Absichten und weil es die Community unbedingt wollte voreilig eingebaut wurden. valarray hat imo durchaus die Chance in ordentlicher Form wiederzukommen. Genauso export templates. Exception-Spezifikationen sind so wie sie sind nutzlos, aber das heißt ja auch noch nicht, dass das unebdingt so bleiben muss.
Ich teile aber deine Befürchtungen was die Größe und Komplexität des nächsten Standards angeht. Auf der anderen Seite ist es natürlich unglaublich leicht rumzujammern und mit dem Finger darauf zu zeigen was alles schlecht ist. Schwieriger ist es es besser zu machen. Obwohl jeder von uns in diesem Moment genau diese Möglichkeit hätte.
-
Artchi schrieb:
Auch wäre es mal angebracht die Lib-Dateien (also das Dateiformat) zu standardisieren, damit man mal Libs zwischen verschiedenen Compilern/Linkern benutzen kann.
Ein standardisiertes Lib-Dateiformat macht IMO nicht allzuviel Sinn (Gründe wurden bereits genug genannt), aber wünschenswert wäre einheitliches Name Mangling, damit man wenigstens aus DLLs in C++ geschriebene Funktionen exportieren kann, ohne die Compilerunabhängigkeit zu verlieren. Natürlich ist die Rückwärtskompatibilität hier ein Problem, aber dafür sollte eine Compiler-Option ausreichen.
Artchi schrieb:
Aber trotzdem vermisse ich grundlegende Dinge in C++ IDEs die nichts mit der fehlenden Reflection zu tun haben.
Was denn genau?
Moritz
-
HumeSikkins schrieb:
Flops über Flops? Ich sehe hier drei Flops die alle mit den besten Absichten und weil es die Community unbedingt wollte voreilig eingebaut wurden.
Ich sage ja nicht, dass das Kommittee sie mit bösen Absichten reingenommen hat. Aber was sich dann in der Praxis als ungeschickt erweist, sollte konsequent wieder rausgeworfen oder zumindest ohne Rücksicht auf Abwärtskompatibilität verbessert werden.
Und ich glaube nicht, dass das geschieht. Wenn ich mir die Proporals so ansehe, geht es viel zu viel um "Erweiterungen". Siehe abartig kaputter ADL -> explicit namespace. Lieber die Sprache ins Lächerliche aufblähen als in den sauren Apfel zu beißen.
HumeSikkins schrieb:
Das ist der Grund warum C++ überhaupt soweit verbreitet ist.
Aber jetzt ist es schon weit verbreitet, selbstständig und hat die Kompatibilität IMHO nicht mehr so nötig wie damals. Ich bin kein Experte aus der Industrie, aber "was man so hört", sind die vielen Fallgruben und die Komplexität von C++ heutzutage ein ganz schönes Gegenargument. Ob es da so wichtig ist, dass man voll ausgereiztes C++98 in jedem Fall kompilieren kann? (Mal davon abgesehen, dass die Compiler heute auch schon daran ersticken.)
