spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"WhiteMike"«

Gibt es da nicht diesen Tipp, dass man an jeder möglichen Stelle ein const setzen sollte, wo es reinpasst?
Fangen wir doch mit unserer Hauptfunktion an ... :-D

	C-/C++-Quelltext
1 2 3 4	int main( const unsigned int argc, const char* const * const argv ) { return 0; }

warum nciht noch const int main?

Zitat von »"WhiteMike"«

Gibt es da nicht diesen Tipp, dass man an jeder möglichen Stelle ein const setzen sollte, wo es reinpasst?
Fangen wir doch mit unserer Hauptfunktion an ... :-D

	C-/C++-Quelltext
1 2 3 4	int main( const unsigned int argc, const char* const * const argv ) { return 0; }

Finde ich eigentlich eine super Sache. Ziehe ich meist recht konsequent durch und bin damit auch recht gut gefahren. Wenn man sich darüber Gedanken macht, ob ein Objekt nun von einer Funktion verändert werden darf oder nicht, zeugt für mich eigentlich von gutem Design.

Zitat von »"WhiteMike"«

Gibt es da nicht diesen Tipp, dass man an jeder möglichen Stelle ein const setzen sollte, wo es reinpasst?

Nein, gibt es nicht. Sowas ist absoluter Schwachsinn.

Zitat von »"the[V«

oid"]Finde ich eigentlich eine super Sache. Ziehe ich meist recht konsequent durch und bin damit auch recht gut gefahren. Wenn man sich darüber Gedanken macht, ob ein Objekt nun von einer Funktion verändert werden darf oder nicht, zeugt für mich eigentlich von gutem Design.

Diese Gedanken hast du aber nicht zu Ende gedacht, oder? Natürlich ist es gutes Design, Const-Correctness zu beachten. Aber das hat nichts mit "überall const wo möglich" zu tun.

Was sollen die folgenden const-Qualifizierer zum Beispiel bringen? Man verhindert, dass die Kopie verändert wird. Sehr sinnvoll. Erstens hat es den Aufrufer nicht zu interessieren, was innerhalb der Funktion geschieht - die Schnittstelle ist das Entscheidende. Zweitens steht der Funktion frei, intern beliebig viele weitere Kopien anzulegen.

Als Rückgabetyp bringt es sogar noch weniger, da skalare RValues generell nicht geändert werden dürfen. Hier wäre int gleichwertig.

Ja klar, bei Parametern ist das so ne Sache, und bei skalaren Rückgabewerten sowieso Blödsinn.
Ich meinte es mehr darauf bezogen, wie wenn man z.B. Variablen innerhalb von Funktionen oder von Membervariablen deklariert.

Zitat von »"the[V«

oid"]Ich meinte es mehr darauf bezogen, wie wenn man z.B. Variablen innerhalb von Funktionen oder von Membervariablen deklariert.

Das hast du zwar vorher etwas anders ausgedrückt, aber naja...

Zitat von »"WhiteMike"«

Mit den Rückgabetypen bin ich einverstanden, aber bei den Parametern kann man sich streiten.
Ich finde, dass es nicht schlimm ist, wenn man verhindert, dass Parametern neue Werte zugewiesen werden dürfen.

Nur um sicherzustellen, dass wir uns richtig verstehen: Ich spreche von kopierten Parametern. Ein const ist hier vielleicht nicht schlimm, aber es hat keinen Vorteil (weshalb, habe ich oben erklärt). Warum sollte man es also tun? Damit es der Auffassung "möglichst viel const ist gut" gerecht wird, die ohnehin völlig daneben ist?

Sowas führt nur zu Verwirrung. Wenn man in der Parameterdeklaration ein const sieht, denkt man als erstes Mal daran, dass eine übergebene Variable von der Funktion nicht verändert werden darf. Dann merkt man, dass keine Zeiger und Referenzen im Spiel sind. Ich fände es hier naheliegend, sich zu fragen, wieso überhaupt ein const verwendet wurde. Das verwässert nur die Schnittstelle mit irrelevanten Informationen, während wirklich wichtige Eigenschaften schon nicht mehr so schnell erkannt werden können.

Wäre übrigens gut, wenn ein Moderator diese Diskussion abkoppeln könnte, wir sind inzwischen ein wenig abgewichen...

Ich teile die Meinung von Nexus voll und ganz. Ich finde const sollte nur in Methoden die keinen Member verändern dürfen und bei zeigern oder referenzen verwendet werden. Für alles andere ist das meist schwachsin, aber es soll auch ausnahmen geben.