[erledigt] 2 reine Verständnisfragen

[Gast]

Hallo Forum!

Ich stehe ganz am Anfang meiner C++-"Karriere" und arbeite mit dem neuen Stroustrup ("Einführung in die Programmierung mit C++").

Dort heißt es u.a. zur Typsicherheit:

int main()
{
  double x;            // wir haben die Initialisierung "vergessen":
                       // der Wert von x ist nicht definiert
  double y = x;        // der Wert von y ist nicht definiert
  double z = 2.0 + x;  // die Bedeutung von + und der Wert von z sind nicht definiert
}

C++-Implementierungen sind autorisiert, solchen Code (...) mit einem Hardwarefehler zu quittieren.

Wie muss ich mir das vorstellen? Wie kann ein solcher Hardwarefehler zustande kommen, warum sollte ein Compilerbauer das nicht ausschließen und warum lässt der Standard eine solche Implementierung zu?

Weiter heißt es:

Ideal wäre es natürlich, nur solche Sprachfeatures zu verwenden, die der Compiler als sicher verifizieren kann (...). Leider ist dieser Ansatz zu restriktiv für die meisten interessanten Programmieraufgaben. Die naheliegende Ausweichlösung wäre, dass der Compiler implizit Code erzeugt, der zur Laufzeit die Typsicherheit prüft (...). Da dies aber jenseits der Möglichkeiten von C++ liegt, (...).

Inwiefern liegt das außerhalb der Möglichkeiten von C++? Weil zur Laufzeit von Typen nichts mehr bekannt ist, wenn die gesamte Logik nur noch in Maschinensprache vorliegt?

[__--]

wenn das da so steht, schmeiß das buch weg. denke aber du hast das aus dem zusammenhang gerissen.

[Gast]

__-- schrieb:

wenn das da so steht, schmeiß das buch weg. denke aber du hast das aus dem zusammenhang gerissen.

Bei jedem anderen Buch würde ich deinem Rat folgen. Aber bei Stroustrup glaube ich irgendwie, dass er schon weiß, wovon er spricht... Andererseits, der Jüngste ist er ja auch nicht mehr.

Aus dem Zusammenhang gerissen habe ich da für mich erkennbar gar nichts, aber da ich kompletter Neuling bin, will ich das natürlich auch nicht ausschließen.

Kann sonst noch jemand was dazu sagen? Ansonsten sollte ich vielleicht einfach mal Stroustrup selbst schreiben; hat jemand Erfahrung mit seiner Antwortfreudigkeit?

[SeppJ]

Für das zu Hardwarefehlern: Das ist die Definition von undefiniertem Verhalten, es darf alles passieren. Wird es in der Regel nicht. Darf es aber.

Zum zweiten: Da fehlt zu viel Zusammenhang bei dem Zitat, als dass ich dazu etwas sagen kann.

[Babelfish]

Da Buch wurde ja auch nicht in Deutsch geschrieben und Stroustrup hat es auch nicht übersetzt.
Da kann auch noch was vom Übersetzter drin sein.

[Gast]

Babelfish schrieb:

Da Buch wurde ja auch nicht in Deutsch geschrieben und Stroustrup hat es auch nicht übersetzt.
Da kann auch noch was vom Übersetzter drin sein.

Daran habe ich auch schon gedacht. Auch deshalb die Idee, Stroustrup einfach mal selbst zu kontaktieren.

[dot]

Ich wär mir sogar sehr sehr sicher dass das einfach eine schlechte Übersetzung ist.

[krümelkacker]

dennis.cpp schrieb:

Ich stehe ganz am Anfang meiner C++-"Karriere" und arbeite mit dem neuen Stroustrup ("Einführung in die Programmierung mit C++").

Dort heißt es u.a. zur Typsicherheit:

C++-Implementierungen sind autorisiert, solchen Code (...) mit einem Hardwarefehler zu quittieren.

Wie muss ich mir das vorstellen? Wie kann ein solcher Hardwarefehler zustande kommen, warum sollte ein Compilerbauer das nicht ausschließen und warum lässt der Standard eine solche Implementierung zu?

Mit "Hardwarefehler" ist hier gemeint, dass die Hardware ein für Fließkommazahlen ungültiges Bitmuster nicht auf sich sitzen lassen muss. Sie kann dann Dinge tun, wie das Programm abbrechen etc. In einfachen Fällen, kann man so etwas zur Compiler-Zeit schon ausschließen. Dazu gibt es auch Compiler-Warnungen. Aber es ist nicht möglich, alle solche Fehler zur Compile-Zeit abzufangen.

dennis.cpp schrieb:

Weiter heißt es:

Ideal wäre es natürlich, nur solche Sprachfeatures zu verwenden, die der Compiler als sicher verifizieren kann (...). Leider ist dieser Ansatz zu restriktiv für die meisten interessanten Programmieraufgaben. Die naheliegende Ausweichlösung wäre, dass der Compiler implizit Code erzeugt, der zur Laufzeit die Typsicherheit prüft (...). Da dies aber jenseits der Möglichkeiten von C++ liegt, (...).

Inwiefern liegt das außerhalb der Möglichkeiten von C++? Weil zur Laufzeit von Typen nichts mehr bekannt ist, wenn die gesamte Logik nur noch in Maschinensprache vorliegt?

Ich rate mal, dass "jenseits der Möglichkeiten" eine Übersetzung von "beyond the scope" ist. In dem Fall, wäre damit gemeint, dass es nicht Sinn un Zweck sein kann, diverse Laufzeitchecks zu erzwingen. Das ist einfach nicht mit der Philosophie von C und C++ vereinbar, die lautet "Don't pay for things you don't use."

kk

[jjjjj]

dennis.cpp schrieb:

Hallo Forum!

Ich stehe ganz am Anfang meiner C++-"Karriere" und arbeite mit dem neuen Stroustrup ("Einführung in die Programmierung mit C++").

Dort heißt es u.a. zur Typsicherheit:

int main()
{
  double x;            // wir haben die Initialisierung "vergessen":
                       // der Wert von x ist nicht definiert
  double y = x;        // der Wert von y ist nicht definiert
  double z = 2.0 + x;  // die Bedeutung von + und der Wert von z sind nicht definiert
}

C++-Implementierungen sind autorisiert, solchen Code (...) mit einem Hardwarefehler zu quittieren.

Wie muss ich mir das vorstellen? Wie kann ein solcher Hardwarefehler zustande kommen, warum sollte ein Compilerbauer das nicht ausschließen und warum lässt der Standard eine solche Implementierung zu?

Weil C++ dem Programmierer die Entscheidungsgewalt gibt. Das hat den Vorteil, dass man sehr schnelle Programme schreiben kann. In deinem Fall hat die Variable x keinen Wert zugewiesen bekommen, deshalb kann sie jeden Wert haben - das Verhalten ist undefiniert.
Der Programmierer muss sich darüber bewusst sein und muss die Variable korrekt initialisieren. Stell dir vor, das würde dem Programmierer abgenommen und hat man einen sehr großen Bereich an Werten:

long x[1000];

Hier würden dann alle Werte zur Sicherheit mit 0 vorinitialisiert. Ist zwar weniger fehleranfällig, aber der Programmierer will das gar nicht, da er die Werte später eh auf 1 und nicht 0 gesetzt haben will. Es würde dann 2x initialisiert werden. Einmal die Sicherheitszuweisung und später die korrekte Zuweisung. Kostet unnötig Laufzeit und deshalb wird das nicht gemacht und der Programmierer muss sich um sein Zeugs selber kümmern.

[Gast]

jjjjj schrieb:

Weil C++ dem Programmierer die Entscheidungsgewalt gibt. Das hat den Vorteil, dass man sehr schnelle Programme schreiben kann. In deinem Fall hat die Variable x keinen Wert zugewiesen bekommen, deshalb kann sie jeden Wert haben - das Verhalten ist undefiniert.

Das hatte ich wohl alles verstanden. Meine Frage war eher, wie ich mir das mit den Hardwarefehlern vorstellen muss, also was da passiert. Und welchen Grund es für einen Compilerhersteller geben könnte, solch ein Verhalten tatsächlich zuzulassen.

Die Antwort von krümelkacker hat mir aber schonmal weitergeholfen. Ich hatte wohl auch ein falsches Verständnis von Hardwarefehler, in diesem Zusammenhang.

Auch kk's zweite Antwort klingt für mich logisch. Ich glaube, für den Anfang genügt mir das als Antwort.

Ich danke euch allen erstmal, werde mich aber bei weiteren Fragen ohne Skrupel wieder melden.

[mleu]

Erst einmal eine Antwort bezüglich der Hardwarefehler:
Im Englischen Original steht das gleiche wie in der Übersetzung:
"An implementation is even allowed to give a hardware error when the uninitialized x is used."

Was Stroustroup meint ist, dass das Verhalten des Programms nicht definiert ist und dass das Programm mit beliebigen Fehlermeldungen abbrechen kann (wie Segmentation Fault, Bus Error, ...). Dies ist in der Regel aber nicht der Fall. Der Grund dies zuzulassen ist, dass dem Compilerbauer dadurch mehr Freiheiten gegeben werden *korrekten* Code zu optimieren.

[mleu]

Nun eine Antwort bezüglich der Typsicherheit. In der deutschen Fassung steht:

Ideal wäre es natürlich, nur solche Sprachfeatures zu verwenden, die der Compiler als sicher verifizieren kann (...). Leider ist dieser Ansatz zu restriktiv für die meisten interessanten Programmieraufgaben. Die naheliegende Ausweichlösung wäre, dass der Compiler implizit Code erzeugt, der zur Laufzeit die Typsicherheit prüft (...). Da dies aber jenseits der Möglichkeiten von C++ liegt, (...).

Im Original steht:

The ideal is never to use language features that the compiler cannot prove to be safe: static type safety. Unfortunately, that’s too re- strictive for most interesting uses of programming. The obvious fallback, that the compiler implicitly generates code that checks for type safety violations and catches all of them, is beyond C++.

"Beyond" wurde also durch "jenseits der Möglichkeiten" übersetzt. Was Stroustroup hier mit "beyond" meint ist leider nicht ganz eindeutig.
Beyond kann man hier (wie schon oben erwähnt) interpretieren als: "nicht der Philosophie von C++ entsprechend". Man kann es aber auch interpretieren als etwas was in den aktuellen C++ Implementierungen nicht möglich ist, da die nötige Information zur Typüberprüfung zur Laufzeit nicht zur Verfügung steht. Dies entspricht der deutschen Übersetzung; zur Klarstellung sollte dort wohl besser so etwas wie "jenseits der Möglichkeiten aktueller C++ Compiler" stehen.

[Gast]

Danke! Gute und nachvollziehbare Antwort. Und danke auch für die Originalzitate!