const correctness oder übertreibe ich es mit const?

GPC schrieb:

[...]

[...]
    const char c = *Str;     //dito
    ++Str; 
[...]

[...]

Das macht >irgendwie< den Sinn von const zunichte

Vergesst mein Posting, hab mich verlesen.

finix

Any schrieb:

GPC schrieb:
[...]
[...]
    const char c = *Str;     //dito
    ++Str; 
[...]
[...]
Das macht >irgendwie< den Sinn von const zunichte

Macht es nicht; ansonsten würde es gar nicht kompilieren.
Nicht der Zeiger sondern der char ist konstant (++Str != ++*Str).

Ich weiß zwar nicht warum du das noch weiter breitschlägst, wo ich doch direkt hinterher schon geschrieben habe, dass ich mich verlesen habe, aber wenn du es wissen willst. Ich dachte ich hätte gelesen, dass da nicht ++Str sondern ++c steht.

khalderon

Also, const ist sehr nützlich. Man soll es nicht vermeiden.
Das folgende ist aber blöd:

const int f(){/*...*/}

Dies ist aber sehr sinnvoll:

const int& f(){/*...*/}

Ich selbst würde immer const schreiben, wenn ich die Möglichkeit dafür habe. D.h. in 90% der Fälle. Die Wahrheit ist, dass in größeren enormen Projekten alles irritierend aussieht- man kann sehr leicht Fehler machen. Dazu gibt es const - um Fehler zu vermeiden.

finix

Any schrieb:

Ich weiß zwar nicht warum du das noch weiter breitschlägst, wo ich doch direkt hinterher schon geschrieben habe, dass ich mich verlesen habe, aber wenn du es wissen willst. Ich dachte ich hätte gelesen, dass da nicht ++Str sondern ++c steht.

Uhrzeit?

HumeSikkins

DStefan schrieb:

Ich würde für das plädieren:

[cpp]
// Rückgabe const int finde ich überflüssig - egal, was Herr Meyers sagt.
int Funktion(const char *String)

Ich bezweifle, dass Scott Meyers const int liefern würde, da ein Return-Value vom Typ int sowieso ein rvalue ist. Ein Konstruktion wie: Funktion() = 22 ist damit auch ohne const ausgeschlossen. Eine solche auszuschließen ist aber gerade das Hauptargument dafür Value-Rückgaben von UDTs als const zu deklarieren. Do as the ints do - quasi

otze

Zdravko schrieb:

Also, const ist sehr nützlich. Man soll es nicht vermeiden.
Das folgende ist aber blöd:
const int f(){/*...*/}
Dies ist aber sehr sinnvoll:
const int& f(){/*...*/}

const referenzen auf build-ins sind nie sinnvoll

Konfusius

// muss hier ein konstanter zeiger auf ein konstantes objekt sein oder 
// reicht ein konstanter zeiger? 
int Funktion(const char *String) 
{ 
  const char *Str = String; // hilft das const hier dem compiler? 

  while (*Str != '\0') 
  { 
    char c = *Str;    // hilft das const hier dem compiler? 

    // ... was machen ... 

    ++Str; 
  } 

  return Irgendwas; 
}

das const vor dem int-rückgabetyp der funktion ist überflüssig, weil die zuweisung Funktion("...")=0 bei einfachen typen sowieso nicht geht. und methodenaufrufe schon garnicht. würde ein objekt zurückgegeben werden, dann wäre das was anderes.

das const zwischen char* und String in der argumentenliste soll wohl bedeuten, daß String auf eine constante zeigt (kA ). also, ich bin bis jetzt immer ohne so nen firlefanz ausgekommen. das bringt wohl nichts. bereits das erste const bewirkt, daß du auf String nur lesend zugreifen kannst.

das const vor char c=Str ist auch übertrieben. es würde zwar sicherstellen, daß c nicht verändert werden kann, das wäre aber bei einer lokalen hilfsvariable total übertrieben.

nur das const in const char *String ist sinnvoll. dadurch wird es möglich, die funktion auch mit stringkonstanten aufzurufen. ohne dieses const würde Funktion("Hallo") einen compilerfehler liefern.

CStoll

otze schrieb:

const referenzen auf build-ins sind nie sinnvoll

Klar sind sie das (besonders wenn du beim Schreiben nicht weißt, ob dort ein built-in oder eine class kommen wird - Strichwort "Template").