const Array mit Variablen initialisieren

Shade Of Mine

Paul Müller schrieb:

Wie ersichtlich, sind alle Deklarationen mit const-Qualifizierer vor dem Bezeichner konstant.
Diese Regel wird bei f durch die Schreibweise von const vor dem Typen verletzt.

Ich bin zwar auch fan von int const gegenüber const int - aber da wird nichts verletzt.

Du liest es einfach falsch. Richtig rum liest man von rechts nach links:
const int

integer (, der) konstant (ist)
int const
konstanter integer

mit Zeigern gehts auch easy:
const int * const
konstanter zeiger auf integer (, der) konstant (ist)

int const * const
ist schöner, weil man so liest:
konstanter zeiger auf konstanten integer

aber falsch oder kompliziert oder so ist hier nichts. Einfach von rechts nach links lesen.

checklist schrieb:

Klar kannst du den Zeiger verändern, aber der Aufrufer bemerkt davon gar nichts, weil du ihn nicht als Referenz übergibst. Wenn ein float *const coeffs verlang wäre, dann ist das naiv (es behütet dich nur vor Flüchtigkeitsfehlern innerhalb der Funktion). Aber um das geht es ja nicht.

Dir scheint nicht ganz klar zu sein, welche Erwartungen im Allgemeinen an ein const gestellt werden. Vielen ist eben nicht klar, dass damit nicht der ganze Ausdruck konstant wird. Ganz zu schweigen davon, was bei der Parameterübergabe passiert. Und das sind nicht nur reine Anfängerfehler. Auch Leute die schon länger mit C oder C++ programmieren, wissen dies nicht. Umso wichtiger ist es einen Anfänger darauf hinzuweisen. Und ihn nicht schnell zu den Unwissenden mit abzustellen.

checklist schrieb:

Ich gebe zu, deine Aufgabe stellt mich vor unlösbare Rätsel: Warum verrätst du die einzige Schwierigkeit schon durch Nummerierung?

Weil es kein Rätsel ist. Wenn es dir aber Fragen aufwirft, so soll es dir helfen diese zu lösen.

checklist schrieb:

Warum codest du nicht direkt in tmp?

In was für ein temp und wozu? Hier geht es um Zuweisbar oder nicht Zuweisbar, und nicht um 100€ bei Wer wird Millionär.
Zugegeben man hätte noch ein paar mehr Spielereien mit einbauen können, um alle Fälle zu zeigen. Du darfst aber gerne selber rum experimentieren.

checklist schrieb:

Wo wird eine Regel verletzt?

Wie man sieht schaust du nur halb hin. Der Text besteht aus zwei Sätzen.

Die aufgestellte Regel heißt:
"Ein Bezeichner ist konstant, wenn vor ihm const steht. Das funktioniert natürlich nur solange const hinter der Typenkennzeichnung steht."
Ist da jetzt etwas falsch dran oder unverständlich?

Btw, wer es noch nicht kennt: http://www.cdecl.org/ . C gibberish English

Shade Of Mine

Paul Müller schrieb:

Die aufgestellte Regel heißt:
"Ein Bezeichner ist konstant, wenn vor ihm const steht. Das funktioniert natürlich nur solange const hinter der Typenkennzeichnung steht."
Ist da jetzt etwas falsch dran oder unverständlich?

Ja und wessen Name auf r endet, der hat immer recht. Nur Paul Müller verletzt diese Regel. :p

Deine "Regel" ist einfach falsch. Das ist das Problem.

Wie gesagt: man liest von rechts nach links (bzw von innen nach aussen, wenn es klammern gibt).

Die Regel wäre falsch, wenn sie nicht stimmen würde. Sie schließt aber nicht aus, dass du const nicht davor schreiben darfst. Insofern macht sie also Sinn, dass man sagen kann, der Bezeichner ist immer konstant, wenn direkt const davor steht. Diese Eindeutigkeit ist aber bei einem const am Anfang nicht gegeben. Und zwar weder für den Bezeichner, noch für den Typ. Da es lediglich eine Ausnahme ist, die es erlaubt dort const davor zu schreiben.
Ich hätte aber auch einfach den Kommentar aus dem Codeschnipsel vorher löschen können, dann gäbe es diese Diskussion nicht.

Fledi

Huch, was hab ich da angerichtet? Nicht streiten, bitte Mein Problem lag an einer anderen Stelle, ich hab die Compilermeldung nur falsch interpretiert. Ihr habt trotzdem geholfen, sonst hätte ich noch ewig gesucht.
Jetzt hab ich endlich ne Echtzeitfilterbank
Danke schön!

Shade Of Mine

Paul Müller schrieb:

Die Regel wäre falsch, wenn sie nicht stimmen würde. Sie schließt aber nicht aus, dass du const nicht davor schreiben darfst. Insofern macht sie also Sinn, dass man sagen kann, der Bezeichner ist immer konstant, wenn direkt const davor steht.

Nur der umkehrschluss ist nicht korrekt.
Die variable ist zwar immer konstant wenn direkt links neben ihr const steht, aber sie ist noch lange nicht immer nicht-const wenn das nicht der Fall ist.

Die richtige Regel ist: von rechts nach links lesen (bzw von innen nach aussen, wenn es klammern gibt). Diese Regel ist immer korrekt.

Deine Regel ist zB in folgendem Code falsch:

int t(int const foo[]) {
  ++foo;
  return *foo;
}

foo ist nicht const. foo ist ein zeiger auf konstante ints.

Das Problem liegt aber eher an deiner unkonventionellen Art einen Zeiger zu deklarieren, als an meiner Merkregel. Die zwar genauso valide ist, wie const davor zu schreiben, aber diese inkonsistente Syntax trägt nicht gerade zur Erleuchtung bei. Ich muss auch sagen, dass ich diese Art der Zeigerübergabe mittlerweile soweit verdrängt habe, dass ich neulich erst mal nachsehen musste, was das eigentlich sein soll.
Ich will hier aber niemanden bekehren, sich eindeutig auszudrücken, was sonst eigentlich immer die Mathematiker gerne machen. Der Code-Schnipsel sollte lediglich zeigen, dass ein Wert nicht gleich const ist, nur weil const davor steht.
Btw, hat dein Beispiel einen weiteren Nachteil. Es ist unmöglich den Zeiger konstant zu bekommen.

Shade Of Mine

Paul Müller schrieb:

Das Problem liegt aber eher an deiner unkonventionellen Art einen Zeiger zu deklarieren, als an meiner Merkregel.

Oder aber die Merkregel ist Schrott?
Es gibt ja massig Ausnahmen was ich alles nicht darf damit die Merkregel passt...

Ich finde ebenfalls int const besser als const int. Aber das ändert nichts daran dass man C++ Code korrekt lesen können muss und deine "Regel" passt da einfach nicht rein. Viel einfacher ist es, es richtig zu lernen: von rechts nach links lesen. So lassen sich auch komplexe Typen lesen.

Michael E.

Paul Müller schrieb:

"const float coeffs[]". (Soll heißen, er will einen Zeiger auf ein konstantes Array

Nein das heißt es wird ein Array übergeben, welches du in der Funktion nicht verändern darfst. Eigentlich wird auch nur ein Zeiger auf ein Array übergeben. Und diesen kannst du sogar verändern, nur die Werte hinter dem Zeiger nicht. Deswegen finde ich diese Verwendung von const auch sehr naiv.

Warum? Dem Aufrufer wird garantiert, dass (aus seiner Sicht) nichts geändert wird, was er der Funktion übergibt. Was ist daran naiv?

Oder aber die Merkregel ist Schrott?

Ja, okay du hast Recht.

Ich hasse es, wie in diesem Forum all meine Falschaussagen auseinandergenommen werden... Vielleicht sollte ich mir einen neuen Nick suchen. Unter diesem hier nimmt mich ja sowieso keiner mehr ernst.

SeppJ

Paul Müller schrieb:

Ich hasse es, wie in diesem Forum all meine Falschaussagen auseinandergenommen werden...

Das ist nichts persönliches, es liegt eher an dem "Falsch" in den Aussagen. Man ist hier eben sehr penibel.

Das war nicht ich, das hat jemand anderes geschrieben.
Vielleicht sollte ich mich mal registrieren.

Paul Müller schrieb:

Das war nicht ich, das hat jemand anderes geschrieben.
Vielleicht sollte ich mich mal registrieren.

Ist schon interessant, dass du weißt, dass das jemand anderes geschrieben hat? Könnte das vielleicht daran liegen, dass du der Nickdieb bist und den Beitrag doch geschrieben hast? Es ist eigentlich Schade, dass es Leute gibt, die hier das Niveau des Golem-Forum einführen möchten. Als ob es nicht schon genügend Spielwiesen für sinnlose Trollerei im Internet gäbe. Ich werde mich hier wohl dann zurück ziehen müssen, weil ich mich lächerlich mache. Aber mache ich mich den wirklich lächerlich, wenn hier ein Troll in meinem Namen postet? Wer weiß, ob nicht du der bist, der die falschen Aussagen streut? Ich finde es Schade, weil ich sicher den einen oder anderen helfen konnte, so hoffe ich. Und btw der echte Paul Müller hat nichts dagegen das seine falschen Aussagen korrigiert werden. Deswegen schreibt man ja auch mal dumme Dinge, damit man lernen kann, wie es richtig geht.
Also tschüss Paul Müller, hallo Random-Nicks. Ist natürlich Mist für die, die gerne wissen möchten wer ihr Gegenüber ist.
Der letzte ernst gemeinte Beitrag, ist der von 15:15. Wobei man an den beiden letzten Inhaltsleeren Posts auch erkennen kann, dass es sich um einen übereifrigen Troll handeln muss.
Und nein ich registriere mich nicht deswegen, weil meine eigenen Fragen verschwindend gering waren und ich bei meinen Ansprechpartnern aus Fleisch und Blut keine Trolle befürchten muss.

Shade Of Mine

Paul Müller schrieb:

Aber mache ich mich den wirklich lächerlich, wenn hier ein Troll in meinem Namen postet?

Ich wuesste nicht warum.
Die Gefahr des Nick-Klau besteht eben wenn man sich nicht registriert. Sehe da aber kein Problem. Wenn du Leuten helfen willst, interessante Diskussionen fuehren und vielleicht auch etwas lernen - warum sollte da ein Name eine Rolle spielen?

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.