Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Wenn ich die Räder absäge mache ich etwas, das nicht vom Hersteller vorgesehen ist. const_casts sind zwar unschön, aber vorgesehen und vollständig definiert. Mit undefined behaviour hat das nichts zu tun.Zitat von »"dot"«
Natürlich kann man const wegcasten. Allerdings braucht das den Compiler nicht zu kümmern. Du kannst bei deinem Auto auch die Räder absägen, dann den Hersteller auf Garantie zu klagen ist wieder eine andre Geschichte... Was const ist wird vom Compiler als const behandelt. Wenn du mit const_cast Mist baust bist du selber schuld (das nennt man dann undefined behaviour). Nur weil man const verwendet bedeutet das noch lange nicht dass man const correct ist...
Zitat von »"Helmut"«
Hi,
hast du dafür Quellen? Ich halte das nämlich für ziemlich großen Quatsch.. const kann nämlich weggecastet oder mit mutable umgangen werden, der Compiler kann also bei Libcalls nicht davon ausgehen, dass ein übergebenes Objekt unverändet bleibt. Und bei moduleigenen Funktionen kann der Compiler genauso gut ohne const herausfinden, ob ein Objekt verändert wird.
Das ist natürlich kein Grund const zu meiden.
Ciao
Zitat
kann der Compiler genauso gut ohne const herausfinden
Zitat von »"Helmut"«
const_casts sind zwar unschön, aber vorgesehen und vollständig definiert. Mit undefined behaviour hat das nichts zu tun.
Zitat von »"Helmut"«
Deshalb kann der Compiler da auch nicht optimieren, weil es sein könnte, dass die Lib absichtlich einen const Parameter übergibt, den man dann casten und verändern soll.
Zitat von »"Helmut"«
Selbst wenn in deinem Beispiel der Nutzer in der Callbackfunktion den Wert castet und verändert wird kein undefiniertes Verhalten entstehen.
Zitat von »"Helmut"«
Aber wie gesagt, die Sprache unterstützt das Brechen dieser Regeln.
Zitat von »"Helmut"«
[...] const kann nämlich weggecastet oder mit mutable umgangen werden, der Compiler kann also bei Libcalls nicht davon ausgehen, dass ein übergebenes Objekt unverändet bleibt.
Naja man muss differenzieren. Wenn ein Objekt ursprünglich mit const deklariert wurde ist eine Veränderung natürlich nicht definiert, meistens werden solche Datenbereiche ja auch im ReadOnly Speicher gehalten. Bei einer const Referenz, die auf ein nicht-konstantes Objekt zeigt, ist das wegcasten von const aber legitim (10.2.7.1 The C++ Programming Language). Der Compiler kann also nur davon ausgehen, dass ein übergebener Parameter gleich bleibt, wenn er beweisen kann, dass die Referenz wirklich auf ein kontant deklariertes Objekt zeigt. Das ist nicht schwieriger, wenn man keine const Referenzen benutzt, was ich ja auch ursprünglich gesagt habe.Zitat von »"dot"«
Zitat von »"Helmut"«
Aber wie gesagt, die Sprache unterstützt das Brechen dieser Regeln.
Nein, die Sprachdefinition sagt dass jegliche Modifikation eines const Objektes zu undefiniertem Verhalten führt. Einzige Ausnahme sind als mutable deklarierte Member von benutzerdefinierten Typen.
C-/C++-Quelltext |
|
1 |
void setfunk(int a,int b,const Obj& c,double d); |
C-/C++-Quelltext |
|
1 |
void setfunk(const int a,const int b,const Obj& c,const double d); |
C-/C++-Quelltext |
|
1 2 3 4 5 6 7 |
class Surface{ private: //... public: const ubyte* getPixels(); //const Daten ubyte* const getPixels(); //const Pointer }; |
C-/C++-Quelltext |
|
1 2 3 4 5 6 |
class Surface{ private: //... public: ubyte* const getPixels() const; }; |
Zitat von »"Helmut"«
Naja man muss differenzieren. Wenn ein Objekt ursprünglich mit const deklariert wurde ist eine Veränderung natürlich nicht definiert, meistens werden solche Datenbereiche ja auch im ReadOnly Speicher gehalten. Bei einer const Referenz, die auf ein nicht-konstantes Objekt zeigt, ist das wegcasten von const aber legitim (10.2.7.1 The C++ Programming Language).
Zitat von »"Helmut"«
Der Compiler kann also nur davon ausgehen, dass ein übergebener Parameter gleich bleibt, wenn er beweisen kann, dass die Referenz wirklich auf ein kontant deklariertes Objekt zeigt.
C-/C++-Quelltext |
|
1 2 3 4 5 6 7 8 9 10 11 |
void blob(const int& x) { int* a = const_cast<int*>(&x); *a = 10; if (x == 5) { // ... } } |
Zitat von »"kiba"«
Man sollte ja immer callbyref benutzen damit Klassen nicht immer kopiert werden müssen, und diese sollte man const setzen.
Aber wie sieht das dann aus wenn einfache Datentypen noch da sind.
Wie sollte man das am bessten schreiben.
Zitat von »"kiba"«
C-/C++-Quelltext
1 2 3 4 5 6 7 class Surface{ private: //... public: const ubyte* getPixels(); //const Daten ubyte* const getPixels(); //const Pointer };
Wäre der konstante Pointer dazu geeignet?
-Die größe des Pixelarrays darf nicht verändert werden.
-Man darf auf die Pixel zugreifen und verändern
Zitat von »"kiba"«
Sollte man Klassenfunktionen die eine Zeiger (einer mebervaraible) wiedergeben als eine Read-Only-Member-Funktionen also constant setzen.?
C-/C++-Quelltext
1 2 3 4 5 6 class Surface{ private: //... public: ubyte* const getPixels() const; };
Denn dann könnte man doch diese Funktion doch in einen konstanten Object aufrufen und die Varaible durch den zeiger verändern.
C-/C++-Quelltext |
|
1 2 3 4 5 6 7 |
class Surface { private: //... public: const ubyte* getPixels() const; ubyte* getPixels(); }; |
Werbeanzeige