Ahja, C++0x. Die neuen Features sehen wirklich nützlich aus, aber ich fürchte, dass viele davon ziemlich der Übersicht schaden. Beispielsweise decltype und auto. Diese Notation für den nachgestellten Return Type ist auch irgendwie arg gewöhnungsbedürftig. Trotzdem freu ich mich drauf und hoffe, dass das bald von möglichst vielen Compilern unterstützt wird und sich auch als Standard gegenüber dem klassischen C++ durchsetzt. Vielleicht ist das dann auch mal ein Ansatz für Microsoft, bisher veräumte Standards nachzuholen. Beispielsweise einige Elemente von C99.
Ich denke nicht, dass C++0x der Sprache in irgendeiner Weise schaden wird, sie ist von Natur aus schon unübersichtlich und erfordert viel Einarbeitungszeit.
Für die Profis ist C++0x ein nützlicher Fortschritt, für die Anfänger ein weiteres Hindernis.
Ich persönlich werde C++ sowieso in Zukunft meiden, wenn möglich und wechsle zu D, das übrigens alles hat, was C++ (inklusive C++0x) hat und mehr.
Ja, D ist toll, nur leider wird es wohl noch dauern, bis man für alle Plattformen einen funktionierenden D Compiler per Paketmanager kriegt. Das ist eigentlich momentan der Hauptgrund, warum ich mich noch nicht näher mit D befasst hab. Außerdem soll die Standardbibliothek nicht sooo toll sein.
Gerade auf decltype und auto freue ich mich (neben den lambdafunktionen) am meissten. Wer auch nur rudimentaer mit Templates arbeitet, wird decltype und auto zu lieben lernen, denn ohne das muss man manchmal so derbe seltsame Konstruktionen betreiben, dass man Traenen in den Augen hat.
Und Lambda-Funktionen haben C++ schon LANGE gefehlt, und die Variante ueber Boost ist auch gewoehnungsbeduerftig.
Um ehrlich zu sein, erwarte ich C++0x seit dem ich das erste Mal davon gelesen habe sehnsuechtig. (!!!)
Allerdings rechne ich ehr, dass aus C++0x ehr sowas wie C++Ax oder C++Fx wird. Lange Zeit haben sie ja sonst nicht mehr. Und wenn man bedenkt, dass Stroustrup auto seit 1982 durchdruecken will, sieht man, wie arschlangsam das Standardisierungskommitee ist. C++ ist zur Zeit leider eine der am wenigsten weiterentwickelten Sprache ueberhaupt, was ich sehr schade finde, denn immerhin war sie ja mal DIE Programmiersprache #1. Langsam hab ich aber das Gefuehl, sie rutscht wie Forth, Fortran und Pascal ziehmlich ab, und verschwindet irgendwann in dem Nieschensegment, wie COBOL.
@Kyuu ... kannst du mal etwas ausfuehrlicher zu D werden ? Vielleicht in einem separaten Thread. Viel hab ich noch nicht von D gehoehrt, und du bist iirc der erste, den ich kenne, der damit ernsthaft arbeitet. Und ein persoenlicher Erfahrungsbericht ist 1000x besser und unterhaltsamer, als sich z.B. die Wikipediaseite dazu durchzulesen.
@DFYX ... nun ja .. die Standardbibliothek von C++ ist auch nicht soo toll (wenn man boost nicht dazu zaehlt als defaktostandard). Ich denke da nur an das Fehlen einfacher regexp- und Stringroutinen, wie z.B. in PHP seit Jahren ueblich.
@DFYX ... nun ja .. die Standardbibliothek von C++ ist auch nicht soo toll (wenn man boost nicht dazu zaehlt als defaktostandard). Ich denke da nur an das Fehlen einfacher regexp- und Stringroutinen, wie z.B. in PHP seit Jahren ueblich.
...
Mit dem Unterschied, dass die D Standardbibliothek noch keine 2 Jahre alt ist und Digital Mars zu niemandem abwärtskompatibel sein musste. Deshalb find ichs schade, dass sie wohl einige Chancen verpasst haben. Details weiß ich aber nicht, hab mich mit D nur mal kurz beschäftigt und das am Rande erfahren. Iirc hat da sogar schon jemand eine alternative Standardbibliothek entwickelt und jetzt darf sich der Entwickler mit inkompatiblen Standards quälen. Allerdings hab ich das wie gesagt nur gehört. Kyuu weiß da sicher mehr.
@Ineluki: Klar. Habe zwar schon eine Weile nichts in D gemacht, da ich im Moment mit einem C++-Projekt beschäftigt bin, aber ich werde es trotzdem gerne tun und der ein oder andere kann mich ja ergänzen/berichtigen.
@DFYX: Mit Standardbibliothek meinst du wahrscheinlich Phobos, die in der Tat relativ mager ist. Glücklicherweise gibt es ja Tango, die ich fast schon auch als Standardbibliothek bezeichnen würde, vor allem da IIRC darauf hingearbeitet wird, dass beide Seite an Seite funktionieren und eventuell irgendwann in der Zukunft fusionieren können, wobei ich mir mit dem Fusionieren nicht sicher bin.
Phobos hat doch nicht wirklich etwas, was Tango brauchen koennte .... sonst finde ich D recht nett, allerdings hat mich Vala D ausgespannt, da ich eher im G-Universum heimisch bin. Tango hat zwar grosse Vortschritte gemacht (wobei man dazu sagen muss, dass ich bereits Tango verwendet habe, bevor Tango fuer die Massen zugaenglich war), aber gio und Co ersetzt es schlichtweg noch lange nicht.
Zitat von DFYX
Ja, D ist toll, nur leider wird es wohl noch dauern, bis man für alle Plattformen einen funktionierenden D Compiler per Paketmanager kriegt. Das ist eigentlich momentan der Hauptgrund, warum ich mich noch nicht näher mit D befasst hab. Außerdem soll die Standardbibliothek nicht sooo toll sein.
...
Das liegt daran, dass sich der gdc-Entwickler weigert, sein Copyright zu uebertragen. Finde ich eigentlich auch richtig so. Dadurch wandert gdc nicht in den gcc Hauptzweig.
--
"When I was in college, there were certain words you couldn't say in front of a girl," "Now you can say them, but you can't say 'girl." - Tom Lehrer
Langsam hab ich aber das Gefuehl, sie rutscht wie Forth, Fortran und Pascal ziehmlich ab, und verschwindet irgendwann in dem Nieschensegment, wie COBOL.
...
Was bei COBOL aber auch nicht wirklich schade ist. Ich hab in der Arbeit sehr viel mit Zig Tausend Zeilen COBOL Code verschiedenster Firmen zu tun und gerademal eine einzige davon hat es geschafft, den Code, zumindest in ihren kleineren Programmen, auf eine einigermaßen verständliche Weise zu Strukturieren. Das einzige das mich in positiver Art und weise fasziniert hat war wie die Records definiert werden. Ich wünschte man könnte in anderen Programmiersprachen dermaßen einfach und übersichtlich Baumstrukturen anlegen.
Gibts für COBOL eigentlich auch noch andere GUI Systeme als diese 3270 Terminals?
Ich kenn mich mit COBOL nicht sonderlich aus. Ist fuer mich nur ein paradebeispiel einer untergegangenen Nieschenprogrammiersprache. Was ist denn am COBOL-Baumkonzept so interessant ?
Beispiel einer Recorddefinition. Code ist von http://www.3480-3590-data-conversion...layouts-1.html
Die erste Zahl gibt den Level des Records an, gefolgt vom Recordnamen. PIC **** ist der Datentyp und die Länge. Im Grunde hast du damit schon deinen Baum. Du kannst damit nicht so viel machen wie in anderen Programmiersprachen aber rein vom Prinzip her ist die Definition des Baumes sehr einfach und übersichtlich.
Wenn du jetzt den Record PRESIDENT hernimmst, dann hast du eine Variable die 23 Zeichen(15+8) lang ist und aus dem Last-Name und dem First-Name besteht. Du kannst entweder den String "MUELLER________MANN____" direkt mit einem Move in President schreiben und dann mit Last-Name oder First-Name auf die entsprechenden Stellen zugreifen, oder du schreibst beides extra in ihre jeweiligen Records hinein. Aber das war dann auch schon die ganze Magie. Mit Cobol kann man nicht die ganze genialität dieser Syntax geniesen.
Achso, das mit dem Ansprechen der Variablen war eher als Beispiel was man dann in COBOL damit anstellen kann gedacht. Was ich hauptsächlich vermisse ist die Möglichkeit, durch irgendwelche Node Objekte auf ähnlich übersichtliche Art und Weise einen Baum zu erstellen.
Das ähnlichste was mir für Java einfallen würde wäre das hier:
Aber gut lesbar ist das nicht und wenn man nen Formatter vorgesetzt bekommt stehen die Chancen gut, dass der die eigene Formattierung über den Haufen wirft.
Ich kenn mich mit COBOL nicht sonderlich aus. Ist fuer mich nur ein paradebeispiel einer untergegangenen Nieschenprogrammiersprache.
...
Untergegangen? Nische? Dir scheint entgangen zu sein, dass heute noch 200 Milliarden Zeilen Cobol Code in Action sind. In Großbritannien hat laut einer Studie ein Bürger am Tag typischerweise 10 mal mit Cobol zu tun... 90% der Finanztransaktionen laufen in Cobol.
Cobol ist vielleicht nicht mehr cool, aber von untergegangen kann kaum eine Rede sein - und selbst über die Nische kann man streiten :-)
Es sind einfach teilweise Jahrzehntelang gewachsene Cobolprojekte im Umlauf die die Firmen brauchen und nicht mal eben in eine andere Sprache umgeschrieben werden können. Die müssen halt weiterhin mit Cobol Code erweitert werden, warum auch nicht, aber erste wahl bei neuen Projekten wird COBOL wohl kaum noch sein.
