spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

const gibts seit dem ersten Standard in C (also seit 20 Jahren)...

prinzipiell habt ihr recht, es ist undefiniert.

aber:

in der praxis sieht es anders aus. da gibt es normal 2 möglichkeiten.

1.) der kompiler erkennt die konstante als konstant und optimiert sie weg.
geht aber nur, wenn die addresse der konstante nicht genommen wird,
und wenn, dann darf sie nicht groß hin und her verschoben werden, sonst
kann er das nicht mehr nachvollziehen. schreibzugriffe überschreiben
den stack oder es fliegt ne exception.

2.) der kompiler erkennt was du mit der armen konstante machen willst und
entfernt das const. damit ist der schreibzugriff wieder definiert. allerdings
hast du keine möglichkeit, herauszufinden ob der kompiler das erkannt hat.

in der debugversion funzt es manchmal, in der release entweder garnicht,
oder der sinnlose zugriff wurde entfernt

Willst du uns damit sagen dass der compiler es entweder so oder so machen kann und man einfach nicht sagen kann was passiert!?
Inwiefern unterscheidet sich das von "undefiniert"!?

Nochmals:

Zitat von »"Nexus"«

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

Und ich denke, damit ist die Diskussion, ob es in der Praxis nur manchmal undefiniertes Verhalten ist und manchmal nicht (nette Definition übrigens), hinfällig. Man sollte grundsätzlich kein const_cast einsetzen, und wenn es doch einmal einen wirklich guten Grund gibt, vergewissert man sich, dass das Objekt ursprünglich nicht const-qualifiziert war.

Klar. Das meiste ist auf Compiler Ebene spezifiziert, allerdings gilt das vielleicht für die nächste Version des Compilers schon nicht mehr.
Und von anderen Compiler mal ganz zu schweigen.

Es ist nicht schwer herauszufinden, was ein Compiler mit bestimmten Einstellungen tut.. Du musst einfach immer damit rechnen, dass er es bereits bei einer kleinen Änderung bereits wieder anderst macht.

Man kann sich da einfach nicht drauf verlassen, weil der Compiler da machen darf, was er will.

Es ist also auch in der Praxis undefiniert.. (wo auch immer du hier die Grenzen zwischen Theorie und Praxis ziehst..)

theorie: der c++ standard
praxis: die kompiler-implementierungen

übrigens wird const_cast sogar in einem buch (ich WEIß nicht mehr welches,
könnte "more effektive c++" sein) empfohlen. hatte was mit der const
und nicht-const version von operator[] zu tun oder sowas

Zitat von »"Gotbread"«

theorie: der c++ standard
praxis: die kompiler-implementierungen

Ich versteh nicht ganz was du eigentlich sagen willst. Was du bisher gesagt hast entspricht in etwa:
Theorie: Straßenverkehrsordnung
Praxis: Autos. Mein Auto ist blau und manchmal ist das Licht an.

Zitat von »"Gotbread"«

übrigens wird const_cast sogar in einem buch (ich WEIß nicht mehr welches,
könnte "more effektive c++" sein) empfohlen. hatte was mit der const
und nicht-const version von operator[] zu tun oder sowas

Ja, in einem der beiden Effective C++ Bücher wird gezeigt wie man const_cast verwenden kann um die Implementierung einer überladenen const Methode in der non const Methode aufzurufen. Dabei handelt es sich um ein Beispel eines der äußerst seltenen Fälle in denen const_cast sicher und nützlich ist. Mit einer generellen "Empfehlung" hat das absolut nichts zu tun.

Sagen wir es so. Ich habe sogar goto bis jetzt öfters verwendet, als const_cast..
OK, es war nur 1 mal, aber somit einiges öfters, als const_cast.

ich nutze beides nicht !

@dot: jooar so kann man das auch sagen

gotos sind manchmal recht sinvoll