irgendwie habe ich immer meine liebe sorge mit der const correctness.

macht zum beispiel folgende funktionsdefinition sinn oder sind hier
überflüssige const drin und wenn ja warum?

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

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

    // ... was machen ...

    ++Str;
  }

  return Irgendwas;
}

thanx...

und wenn ja warum?

ich würd's so machen:

//kein return-const, da eh by-value Rückgabe
//mir reicht's, wenn das Objekt String konstant ist, der Zeiger muss es für
//mich nicht sein
int Funktion(const char* String) {
  const char *Str = String;  //oben ham wir const, also nehm ich's hier auch

  while (*Str != '\0')  { 
    const char c = *Str;     //dito
    ++Str; 
  } 

  return Irgendwas; 
}

MfG

GPC

// Rückgabe const int finde ich überflüssig - egal, was Herr Meyers sagt.
int Funktion(const char *String)
{
  // Keine Kopie von String notwendig.
  while (*String)
  {

    // ... was mit *String machen ...
    // Keine Kopie von *String notwendig 

    ++String;
  }

  return Irgendwas;
}

Wo mir const übrigens noch am Herzen liegt, sind Memberfunktionen...

Stefan.

[...]

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

[...]

Das macht >irgendwie< den Sinn von const zunichte

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).

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.

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?

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

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

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.

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").