const Array mit Variablen initialisieren

Prinzipiell ist der Name egal. Nur zwei Personen mit dem selben Namen sind verwirrend.
Aber um noch mal auf "meine Merkregel" zurück zu kommen. Mich würde dann doch stark interessieren, welche Fälle es noch gibt, außer diese Array-Deklaration?
Mir ist es eigentlich auch wurscht was andere davon halten. Man sieht es nur recht selten, eigentlich nie, dass die anderen Teile des Datentypen konstant gemacht werden können, bzw bei Bedarf gemacht werden müssen. Statt dessen sieht man es umso häufiger, dass man ein const davor schreibt und hofft, dass sich die Sache damit erledigt hat.
Und was die Sache mit der Lächerlichkeit betrifft. Wenns dich nicht interessiert, dann ignoriere es einfach. Wenns dich erheitert dann erfreu dich dran. Aber mit sinnlosem Nickklau, wirst du weder wissen, ob du mich ignorieren sollst, dich erheitern kannst oder etwas lernen kannst. Das ist eben das Los der sinnbefreiten Trollerei.

zeusosc

http://www.parashift.com/c++-faq-lite/const-correctness.html

Ist so eine Merkregel überhaupt nötig/sinnvoll?

Im Grunde genommen gibt es doch nur drei Variablentypen (weiß nicht wie ich die besser unterscheiden kann):
1. "normale" Variablen, also z.B. int a; double b; MyClass c;
2. Zeigervariablen, also z.B. const int* a; double * const b;
3. Referenzen, also z.B. const int& a = 1; MyClass& b = MyClass()

1. und 3. verhalten sich im Bezug auf const exakt gleich; man kann sich auch gar nicht vertun, weil es nur eine Semantik gibt.
Bei 2. gibt es zwei Möglichkeiten, wobei man beide sehr leicht unterscheiden kann:

const vor dem Sternchen -> Zeiger zeigt auf konstantes Objekt
const nach dem Sternchen -> Zeiger selbst ist konstant

Also wozu irgendwelche Merkregeln, wenn es doch beim entscheidenen Fall 2. (der einzige, bei dem man etwas falsch machen könnte) sowieso nur zwei Möglichkeiten gibt?

314159265358979

Wie siehts aus mit Zeigern auf Funktionen. Zeigern auf konstante Funktionen. Zeigern auf Zeigern. :p

Merkregel schrieb:

2. Zeigervariablen, also z.B. const int* a; double * const b;

Das Problem an dieser Unterscheidung ist aber, dass ein Zeiger auch eine normale Variable ist. Und dieser Zeiger kann konstant sein, aber auch das referenzierte Objekt kann konstant sein. Was ein Unterschied ist. Es gibt aber auch Zeiger, auf Zeiger. Und diese können auch eine Konstantheit aufweisen. Deswegen ist es wichtig zu wissen, auf was sich genau ein Schlüsselwort bezieht. Und das ist das was vor const steht. Ganz klar wird es bei Methoden. Dort kann ich auch bei void nicht const davor schreiben, auch wenn es offensichtlich ist, dass void nicht const sein kann. Einen anderen Grund, als diese Offensichtlichkeit kann ich mir zumindest nicht vorstellen, warum es überhaupt erlaubt ist diese Ausnahme bei Variablen zu schreiben.
Und in die Parameterliste einer Funktion eine Array-Deklaration zu schreiben ist unschön, weil es kein Array ist, sondern ein Zeiger.
Ein Array hat auch dieses Problem gar nicht, ob man nun den Zeiger (den es hier eigentlich nicht gibt) konstant deklarieren soll oder nicht, ein Array hat immer eine konstante Adresse.

Merkregel schrieb:

Also wozu irgendwelche Merkregeln, wenn es doch beim entscheidenen Fall 2. (der einzige, bei dem man etwas falsch machen könnte) sowieso nur zwei Möglichkeiten gibt?

Weil zwei Möglichkeiten schon eine zuviel ist. Und die Merkregel auch nur in den Codeschnipsel gerutscht ist, weil ich den nicht extra geschrieben habe. Dass wollte ich gar nicht ansprechen.
Es ist halt unschön, weil es unnötige Fragen aufwirft. Und gerade Anfänger haben so schon genug Fragen, die muss man nicht noch extra verwirren.

Merkregel schrieb:

3. Referenzen, also z.B. const int& a = 1; MyClass& b = MyClass()

Referenzen sind übrigens auch so ein Fall, wie bei den Arrays, wo eine const Deklaration gar nicht notwendig ist, weil sie implizit geschieht. Eine Referenz ist immer an ein Objekt gebunden und die Semantik lässt es auch gar nicht zu diese Bindung zu ändern.

Btw, kann man von einem temporären Objekt keine Referenz bilden. Weil es im gleichen Augenblick wieder zerstört wird.

314159265358979

Paul Müller schrieb:

Referenzen sind übrigens auch so ein Fall, wie bei den Arrays, wo eine const Deklaration gar nicht notwendig ist, weil sie implizit geschieht. Eine Referenz ist immer an ein Objekt gebunden und die Semantik lässt es auch gar nicht zu diese Bindung zu ändern.

Das const bezieht sich doch auf das Objekt, auf das sich die Referenz bezieht, deshalb macht die Unterscheidung schon Sinn.

Ja, aber ein const hinter dem Und-Zeichen macht keinen Sinn, weil ich die Referenz nicht ändern kann.

Wie siehts aus mit Zeigern auf Funktionen. Zeigern auf konstante Funktionen. Zeigern auf Zeigern. :p

Stimmt, die Funktionszeiger haben auch noch eine etwas eigentümliche Syntax.

Es gibt aber auch Zeiger, auf Zeiger. Und diese können auch eine Konstantheit aufweisen. Deswegen ist es wichtig zu wissen, auf was sich genau ein Schlüsselwort bezieht.

Ja, das stimmt. Trotzdem denke ich, dass das auch ohne die Regel, dass sich const immer auf das Vorrangegangene bezieht klar ist. Wie der Schatten meiner Selbst gesagt hat: Man ließt einfach von rechts nach links und schon ist wieder alles konsisten. Alles Ansichtssache.

Referenzen sind übrigens auch so ein Fall, wie bei den Arrays, wo eine const Deklaration gar nicht notwendig ist

Natürlich sind sie notwendig. Wie sonst soll ich dem Aufrufer klar machen, dass ich sein Objekt nicht verändere? Natürlich kann ich die Referenz nicht "umbiegen" (weswegen konstante Referenz eigentlich ein weißer Schimmel ist - richtig wäre: Referenz auf konstantes Objekt), aber das referenzierte Objekt kann ich sehr wohl verändern, falls es nicht durch ein const verhindert wird.

Btw, kann man von einem temporären Objekt keine Referenz bilden. Weil es im gleichen Augenblick wieder zerstört wird.

Kann man schon, aber es ist böse. War auch nur um den Beispielcode kurz zu halten.

Ja, aber ein const hinter dem Und-Zeichen macht keinen Sinn, weil ich die Referenz nicht ändern kann.

Wusste bisher gar nicht, dass das überhaupt erlaubt ist...