Was ist denn nun mit diesem neuen C++ Standard?
-
Ergänzend:
http://www2.research.att.com/~bs/C++0xFAQ.html <-- !!!
http://www.artima.com/shop/overview_of_the_new_cpp
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum C++ (auch C++0x, bzw. C++11) verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
oioioi schrieb:
Unterstützen die compiler diesen schon? Was hat er tolles zu bieten?
Für mich viel wichtiger: Nachdem nun ein neuer Standard verabschiedet wurde... Wechseln nun die Lehrer endlich mal zumindest auf den 98 Standard? ;p
(Und nein, nicht weil ich was mit Schule zu tun hätte, sondern weil mir die Auswüchse auf den S*** gehen).
-
asc schrieb:
oioioi schrieb:
Unterstützen die compiler diesen schon? Was hat er tolles zu bieten?
Für mich viel wichtiger: Nachdem nun ein neuer Standard verabschiedet wurde... Wechseln nun die Lehrer endlich mal zumindest auf den 98 Standard? ;p
(Und nein, nicht weil ich was mit Schule zu tun hätte, sondern weil mir die Auswüchse auf den S*** gehen).Berechtigte Frage. Ich kann mich erinnern, dass mein ehemaliger Physilehrer aus der Mittelstufe (Gymnasium) einen Lehrplan hatte, bei dem die technische Entwicklung 1980 aufhörte. Dieses Jahr dürfte wohl mit seinem Abschlussjahr fürs Lehramt zusammenfallen. Er hatte seinen Lehrplan einmal aufgestellt und diesen jedes Jahr heruntergeleiert. Eine interessante Form von Lernresistenz.
-
> bei dem die technische Entwicklung 1980 aufhörte.
Spielt auf dem Gymnasium keine Rolle. Sachen wie einen Teilchenbeschleuniger oder einen Tokamak-Reaktor wird man wohl nur schematisch behandeln, und schematisch (oberflächlich) betrachtet ist da zwischen 1980 in 2011 kein Unterschied.
-
aber grad in der informatik schon. das ist ja fast die halbe lebenszeit dieser wissenschaft
-
Skym0sh0 schrieb:
aber grad in der informatik schon. das ist ja fast die halbe lebenszeit dieser wissenschaft
So viele neue Technicken & co jedes Jahr (gar jeden monat) neu auf dem Markt. Da sind 20 Jahre unglaublich viel 
-
Jodocus schrieb:
> bei dem die technische Entwicklung 1980 aufhörte.
Spielt auf dem Gymnasium keine Rolle.
Wie auch von anderen gesagt: Die Informatik gehört zu den schnelllebigsten Disziplinen, selbst die grundlegende Regeln ändern sich nicht selten.
Und ich erwarte das zumindest das gelehrte grundlegend richtig ist. Meine bisherige Erfahrung von Informatikunterricht und gerade C++ ist: Es wird grundlegend fehlerhaftes gelehrt, was selbst in den Anfangszeiten von C++ schon verkehrt war. Und ich erwarte durchaus auch von Lehrern das sie ab und zu ihr Wissen auffrischen. Ich verlange ja gar nicht, das Lehrer immer auf dem aktuellsten Stand sind, aber alle paar Jahre mal das gelehrte zu überprüfen schadet wirklich nichts.
Viele legen einmal gelerntes nur sehr langsam ab. Daher erwarte ich durchaus das man auch versucht Wissen richtig und verständlich zu vermitteln.
-
#include <iostream.h>
-
Skym0sh0 schrieb:
#include <iostream.h>Wer sowas noch im Kurs zulässt...
Wie volkard schon mal schön sagte (oder wars SeppJ?):"Die Lehrer sind immer noch in den wilden Neunzigern..."
-
Hacker_ausgeloggt schrieb:
Skym0sh0 schrieb:
#include <iostream.h>Wer sowas noch im Kurs zulässt...
Ach, das finde ich persönlich wesentlich unproblematischer als der Programmierstil und die teilweise gravierenden Fehler (die gerne in undefiniertes Verhalten enden) die gelehrt werden. Hier muss man sich wenigstens nur das .h ab- und den namensraum std angewöhnen.
-
asc schrieb:
Und ich erwarte das zumindest das gelehrte grundlegend richtig ist. Meine bisherige Erfahrung von Informatikunterricht und gerade C++ ist: Es wird grundlegend fehlerhaftes gelehrt, was selbst in den Anfangszeiten von C++ schon verkehrt war.
Leider muss man es aber in der Klausur so machen, wie es in der Vorlesung gelehrt wurde. Meist ist es dann so, wenn der Dozent in der C++ Klausur etwas nicht versteht, ist es für ihn falsch (wobei ich auch schon einen hatte, der Quellcodes abgetippt hat, wenn er was nicht verstanden hat). Letztendlich ist es doch so, dass man für 100% Fachwissen keine 1 in der Klausur bekommt.
-
Gugelmoser schrieb:
Letztendlich ist es doch so, dass man für 100% Fachwissen keine 1 in der Klausur bekommt.
Zum Glück gibt es (aber leider seltene) Ausnahmen...
Im Studium gab es zwei paralelle Programmierkurse (beide C++), in dem einen führte ein nicht ausführbares Programm (egal aus welchen Grund) automatisch zu einer 5 oder 6, und die Codequalität etc wurde nicht überprüft.
In dem anderen Kurs nahm sich der Dozent Zeit, und schaute auch in den Sourcecode. Das konnte dazu führen, das ein Sourcecode der am Ende der Prüfung nicht lauffähig war dennoch eine gute Note einbrachte, und ein Sourcecode der zwar lief aber die Aufgabenstellung komplett verfehlte eine schlechte Note einbrachte. Dieser Dozent bewertete das "Gesamtbild".
-
asc schrieb:
Im Studium gab es zwei paralelle Programmierkurse (beide C++), in dem einen führte ein nicht ausführbares Programm (egal aus welchen Grund) automatisch zu einer 5 oder 6, und die Codequalität etc wurde nicht überprüft.
Das war bei uns auch so, und das hat meist 1/3 der Klasse getroffen, die sich dann alle beim Dekan beschwert haben :D. Ich hatte 2 Semester C++. Bei uns wurde z.B. nie Templates durchgenommen oder std::vector verwendet. Wir hatten voll das C/C++ Gemisch. Zur Vorlesung gab es immer ein Praktikum dazu. Wenn man da was verwendet hat, das in der Vorlesung nicht dran kam, hat man manchmal noch einen Anschiss kassiert oO.
asc schrieb:
In dem anderen Kurs nahm sich der Dozent Zeit, und schaute auch in den Sourcecode. Das konnte dazu führen, das ein Sourcecode der am Ende der Prüfung nicht lauffähig war dennoch eine gute Note einbrachte, und ein Sourcecode der zwar lief aber die Aufgabenstellung komplett verfehlte eine schlechte Note einbrachte. Dieser Dozent bewertete das "Gesamtbild".
Das ist mal entgegenkommend :).
-
Leute: Informatik und Compiler-Standards sind völlig verschiedene Dinge. Die Informatik will eine Wissenschaft sein. Die Hersteller von Compilern stellen nur Werkzeuge für jedermanns Gebrauch bereit und passen diese Werkzeuge gelegentlich an. Solche Anpassungen basieren aber nur selten auf wissenschatflich neuen Erkenntnissen, sie sind eher praxisorientiert und auch für Nicht-Informatiker verständlich und einsetzbar.
-
berniebutt schrieb:
Compiler-Standards
Zum wiederholten Male: Nicht die Compiler sind standardisiert, sondern die Sprache.
-
Michael E. schrieb:
berniebutt schrieb:
Compiler-Standards
Zum wiederholten Male: Nicht die Compiler sind standardisiert, sondern die Sprache.
Das wurde schon mal gesagt? Mir scheint, dass das eine das andere impliziert.
Der Standard fängt ja auch so an1 General [intro]
1.1 Scope [intro.scope]
1 This International Standard specifies requirements for implementations of the C++ programming language. The first such requirement is that they implement the language, and so this International Standard also defines C++. Other requirements and relaxations of the first requirement appear at various places within this International Standard.C++ wird auch beschrieben, aber angefangen wird mit der Implementierung - wobei nicht verlangt wird, dass es sich dabei um einen Compiler handelt. Zudem macht die Bedingung, bestimmte fehlerhafte Konstrukte diagnostizieren zu müssen, keinen Sinn, falls nur die Sprache standardisiert werden sollte.
-
This International Standard specifies requirements for implementations of the C++ programming language. The first such requirement is that they implement the language, and so this International Standard also defines C++
Deine Übersetzung ist nicht greade sinngemäß.
Dieser Standard spezifiziert die Anforderungen für die Implementierung der C++ Programmiersprache. Die Erste solche Anforderung ist, dass Sie die Sprache erfüllen, und ebenso definiert dieser Standard C++.
Ein Standardisierungsprozess würde mindestens bedeuten, dass die Compilerhersteller ihre Implementierung gegen ein Testframework fehlerfrei laufen muss. Weder Microsoft, Embarcadero, Intel, GNU machen dies. Und ich glaub auch nicht, dass die ISO so ein Testframework aufgebaut hat. Also bleibt der Standard als die Spezifikation der C++ Programmiersprachen.
-
Zeus schrieb:
Ein Standardisierungsprozess würde mindestens bedeuten, dass die Compilerhersteller ihre Implementierung gegen ein Testframework fehlerfrei laufen muss.
Und das steht wo?
-
Ich seh die Abgrenzung zwischen Sprachstandard und Compilerstandard auch, so wie Zeus und Michael E. - allerdings ist diese Abgrenzung schwer zu erklären. Hier ein Versuch:
Der C++-Sprachstandard definiert, was "Implementierungen der Sprache" mindestens zu leisten haben, um die Sprache C++ im Sinne des Standards zu übersetzen. Es geht dabei also nicht nur um die Definition der Sprache selber, sondern um ein Set von Übersetzungsregeln. Das beinhaltet natürlich komplett die Beschreibung dessen, was übersetzt werden kann.
Zudem macht die Bedingung, bestimmte fehlerhafte Konstrukte diagnostizieren zu müssen, keinen Sinn, falls nur die Sprache standardisiert werden sollte.
Zu einer ordnungsgemäßen Übersetzung kann auch gehören, nicht übersetzbare Quellen als solche zu kennzeichnen.
Compilerstandards, wenn es sie denn gäbe, würden beschreiben, wie die Übersetzungsregeln umzusetzen sind. Unter anderem wären das z.B. Regeln, wie Fehler zu diagnostizieren sind, welche Warnungen auszugeben sind, auf welche Weise templates zu instanziieren sind, und zig andere Dinge, die das, was der Sprach-Standard den Implementierungen überlässt, noch weiter einschränken.
camper schrieb:
angefangen wird mit der Implementierung - wobei nicht verlangt wird, dass es sich dabei um einen Compiler handelt.
Jein. [lex.phases], Abschnitt 7 impliziert, dass die Implementierung unter anderen einen Compiler beinhaltet, der aus Übersetzungseinheiten übersetzte Übersetzungseinheiten macht. Der Standard beschränkt sich aber nicht darauf. Ein Linker wird auf jeden Fall auch benötigt (Phase 9), ferner gehören die Bibliotheken zur Implementierung, die Laufzeitumgebung, die benötigt wird, um übersetzte Programme ausführen zu können etc. [intro.compliance], Abschnitt 7, erlaubt außerdem auch "freestanding implementations", die sowas wie ein eigenständiges Laufzeitsystem inklusive Möglichkeit zur Erfassung von Sourcecode darstellen, also quasi ein integriertes Betriebssystem mit eingebautem Präprozessor, Compiler, Linker und Laufzeitumgebung.