ich habe eine klasse mit vielen set-methoden und hab mir überlegt überall die parameter als referenz zu machen. gibt es was gegen:

set_timeout( const unsigned int &timeout )

einzuwenden? warum macht man nicht überall diese referenzen hin ?

warum? wenn er es als Referenz übergeben will?

Da steht ein const davor => sinnlos

Die Größe der Variable die kopiert wird und die der Referenz ist identisch. Daher kein Vorteil.

Wer sagt das? Woher willst du wissen, das der Compiler Referenzen als Pointer implementiert? Ist das nicht eher Compiler-abhängig? Und somit eine Pauschalaussage nicht wirklich richtig?

cu André

Basingstoke schrieb:

warum? wenn er es als Referenz übergeben will?

Da steht ein const davor => sinnlos

ähh nö - wieso ?
Der Unterschied zwischen einer const- und einer non-const-Referenz sollte doch wohl auf der Hand liegen, oder ?
Selbst bei einem Call by Value kann ein const eine "Programmierhilfe" sein, wenn man sicherstellen will, dass man bei der Implementation nur const-Funktionen auf die Kopie anwenden will ... (MUSS man nicht, mache ich auch eher selten, ist aber nicht per definitionem sinnlos - spätestens bei templates ist das gar nicht so dumm)

Gruß,

Simon2.

war wohl auf die ersten beiden Antworten bezogen

er meint sinnlos, weil man es dann nicht wirklich als Referenz verwenden will, sondern nur den Geschwindigkeitsvorteil haben will.

war wohl auf die ersten beiden Antworten bezogen

richtig

Und so Aussagen "woher wollt ihr wissen, dass Referenzen als Pointer implementier sind?" haben auch maximal theoretischen Wert. Jeder mir bekannte Compiler implementiert Referenzen durch Pointer (auch irgendwie naheliegend), also macht es keinen Sinn über irgendwelche theoretischen Möglichkeiten zu reden.

Ergo: primitive Datentypen => Value
sonst => Referenz (wenns geht)

mhm schrieb:

er meint sinnlos, weil man es dann nicht wirklich als Referenz verwenden will, ...

richtig...

Aha !
Merke: Wenn man schreibt, was man meint, wird man weniger mißverstanden.

Gruß,

Simon2.

Konstante Referenzen kann man auch verändern, dazu ist ja const_cast da. Also schon ein Unterschied.

Nein, dafür ist const_cast eben nicht da. Konstante Werte sollte man niemals ändern. const_cast hat vor allem die Bewandnis das man allte Schnittstellen (z.B. externe) verwenden kann wo - obwohl keine Änderung erfolgt - keine const-Deklaration statt gefunden hat.

cu André

... Konstante Werte sollte man niemals ändern....

Richtig. Aber man kann. Und daher ist es ein Unterschied. Habe ja nicht gesagt das man es soll.

...Aber man kann....

... und springt damit über die Grenzen des Standards hinaus in den weiten Raum "undefiniertes Verhalten".
Mit Deiner Formulierung suggerierst Du aber Anderes.

Genauso könnte ich sagen: "Pi kann man als 2 definieren".
Da gilt auch: "Ja, man kann"
.. aber eben auch: "Dann sollte man sich aber nicht darauf verlassen, dass alles Andere noch funktioniert/gilt"

Gruß,

Simon2.

undefiniert eben.

Du hast geschrieben (in einer allgemeinen Diskussion über Schnittstellen):

Fellhuhn schrieb:

Konstante Referenzen kann man auch verändern, dazu ist ja const_cast da....

... und das stimmt einfach nicht.
Stattdessen hat asc es gut auf den Punkt gebracht:

asc schrieb:

...
Nein, dafür ist const_cast eben nicht da. Konstante Werte sollte man niemals ändern. const_cast hat vor allem die Bewandnis das man allte Schnittstellen (z.B. externe) verwenden kann wo - obwohl keine Änderung erfolgt - keine const-Deklaration statt gefunden hat....

... und dieses "sollte man niemals ändern" ist nicht ein netter Design-Tipp unter Freunden, sondern eine andere Formulierung von "Ergebnis ist undefiniert".
Manchmal ist "undefiniert" das geringere Übel und da ist const_cast das Mittel der Wahl, aber es ist nicht das generelle Mittel, um "... konstante Referenzen zu ändern ...".

Gruß,

Simon2.

Das ist kein Stück undefiniert.

Doch, das ist undefiniert. 'const_cast' darf lt. Standard nur auf Werte angewandt werden, die nicht 'const' angelegt worden sind (ich bin zu faul, den genauen Wortlaut herauszusuchen). Wenn man 'i' also non-const deklariert hätte, wäre der Code wohldefiniert, sonst nicht. (Zumindest ist es bei Zeigern so, ob das auch für Referenzen gilt, weiß ich nicht.)

Das ist kein Stück undefiniert. "Definierter" geht es gar nicht.

Nein. Es ist undefiniert. Das "entconsten" einer konstanten Variable (Beachte: Das Ursprungsobjekt ist konstant!) führt zu undefiniertem Verhalten. Punkt.

Was Du wahrscheinlich meinst ist:

void f(int const& fi);

int main() {
   int i = 3; // KEIN const
   f(i);
   cout << i;
   return 0;
}

void f(int const& fi) {
   int& i = const_cast<int>(fi);
   i++;
}

BTW: Beim cast fehlt glaube ich ein & in den <>.