spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Gibt es einen vernünftigen Grund, das undefinierte Verhalten herauszufordern? Wegcasten von Constness ist in 99% der Fälle der reinste Designfehler.

Zitat von »"defaultplayer"«

Wäre das Verhalten auch noch undefiniert, wenn der Compiler immer den Wert im Speicher nehmen würde?

Ja. Undefiniert bedeutet dass nicht definiert ist was passiert. Und wenn dein Compiler unter bestimmten Umständen den Wert im Speicher nimmt dann ist das trozdem noch undefiniert. Sobald du versuchst ein konstantes Objekt zu verändern (wie auch immer du das machst) ist das undefiniert.

Zitat von »"defaultplayer"«

Ich hab gerade bemerkt, dass der Code (im Grunde der von vorher) funktioniert (also die Konstante geändert wird), wenn ich bei VS einstelle, dass er es als C-Code kompilieren soll.

Undefiniert bedeutet auch nicht dass das Programm abstürzt. Es bedeutet einfach dass nicht definiert ist was passiert. Dein Programm kann abstürzen, es kann auch funktionieren, es kann auch eine Email mit dem Betreff "Hello World" an alle Leute in deinem Adressbuch deren zweiter Vornname mit F anfängt schicken, es kann ...
Undefiniert heißt dass die Sprache C++ nicht definiert was das von einem standardkonformen Compiler erzeugte Programm tun wird. Das ist alles. (Es ist aber durchaus möglich dass dein Compiler für einige undefinierte Konstrukte sehr wohl definiert was passiert, allerdings hat das nicht mit der Sprache C++ sondern mit deinem Compiler zu tun und liefert auf einem anderen Compiler evtl. andere Ergebnisse).
Das da oben ist übrigens auch in C genauso undefiniert und illustriert eigentlich schön wie mit anderem Compiler bzw. nur anderen Einstellungen auf einmal ganz was andres rauskommt...

Zitat von »"defaultplayer"«

Wäre das Verhalten auch noch undefiniert, wenn der Compiler immer den Wert im Speicher nehmen würde?

Wer sagt dir denn, dass die Werte in einem schreibbaren Speicher landen?

Du solltest mit "undefined behaviour" wirklich sehr vorsichtig sein. In den meisten Fällen muss man einfach wissen, was erlaubt ist und was nicht. Und versuch ja nicht, durch Messungen und bestimmte Verhaltensweisen trotzdem Rückschlüsse zu ziehen ("geht, ist also nicht undefiniert").

Hey mal so ne frage: Wenn das ändern einer Konstante sowieso undefiniert ist, warum gibt es dann const_cast? Ich meine, ist doch total Sinnlos, doch nicht etwa nur, weil manche Programmierer kein const benutzen und dass man deren Codes trotzdem benutzen kann? oO

Socke

Das verändern konstanter Objekte ist undefiniert.



das z.B. wäre nicht undefiniert, p zeigt auf ein nicht konstantes Objekt (auch wenn der Typ des Zeigers const int* sein mag)...

Zitat von »"defaultplayer"«

Wäre das Verhalten auch noch undefiniert, wenn der Compiler immer den Wert im Speicher nehmen würde?


Ich hab gerade bemerkt, dass der Code (im Grunde der von vorher) funktioniert (also die Konstante geändert wird), wenn ich bei VS einstelle, dass er es als C-Code kompilieren soll.

	C-/C++-Quelltext
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	#include <conio.h> #include <stdio.h> int main() { const int a = 4; int* c; printf("%d\n", a); c = (int*)&a; // <<<<<< *c = 5; printf("%d\n", a); getch(); }

Bei der markierten Zeile ist, wenn der Code als C-Code behandelt wird, der explizite Cast nicht notwendig.

In C gibt es kein const. Entweder da steht irgendwo ein #define const drin, dann ist das Programm sehr wohl definiert, oder es dürfte nicht kompilieren.

ciao

Zitat von »"Helmut"«

In C gibt es kein const.

Klar gibts const in C

Oh stimmt, haben die inzwischen schon dazugepackt