Parameter als Referenz übergeben unnötig?

[SeppJ]

Dicker schrieb:

Einleuchtend mit der getrennten Kompilierung. Aber könnte nicht der Linker den Zwischencode analysieren und dann entsprechend optimierten Code liefern?

Ja, das gibt es neuerdings und du darfst durchaus davon ausgehen, dass solche Optimierungen dann auch möglich werden.

Ich möchte einfach gerade nur herausfinden, wie wichtig es ist, den Code selber zu optimieren,

Das wichtigste ist erst einmal, dass der Algorithmus stimmt. Und man sollte keine großen Dummheiten machen. Denn eine unnötige Kopie eines großen Objekts wegzuoptimieren, ist dann doch schon eine ziemlich große Aktion, da machst du es lieber gleich richtig. Zwischen Kopie und const-Referenz besteht dann nämlich doch ein großer Unterschied, das lässt sich nicht unbedingt äquivalent austauschen. Und man sollte sich mal die C++11-Mittel angucken, dem Compiler noch mehr entgegen zu kommen, um solche Kopien zu vermeiden.
Kleinere Optimierungen in einfachen Rechnungen werden hingegen in der Regel extrem gut optimiert:

z.B. schlagen einige Leute vor, dass Bit-Schiebe-Operationen schneller seien als das multiplizieren mit einer 2er-Potenz.

Dies zum Beispiel galt vielleicht mal vor vielen Jahrzehnten.

Oder das Benutzen von inline-Funktionen.

Noch so ein Beispiel dafür: Inline ist praktisch nur noch wegen seines Einflusses auf die Bindung von Bedeutung. Wenn der Compiler (oder ein optimierender Linker) den Funktionscode vorliegen hat, wird er die Möglichkeit von Inlining prüfen, egal ob inline oder nicht. Wenn er die Funktion nicht vorliegen hat, dann ist es egal ob sie inline ist oder nicht, dann wird eben ein normaler Call gemacht.
Daraus kannst du aber immerhin mitnehmen, dass es eine gute Idee ist, wenn kleine Funktionen dem Compiler als Code vorliegt (wofür sie in der Regel auch inline sein muss, falls man sie in mehreren ÜË benutzt). Oder falls dies nicht möglich ist, dann sollte man zur Linkzeit optimieren.

[Eisflamme]

Eigentlich ist doch jede Referenz konstant, oder?

[SeppJ]

Eisflamme schrieb:

Eigentlich ist doch jede Referenz konstant, oder?

Eben. Konstante Referenz ist daher eine Tautologie. Und zwar eine böse, denn der Sprecher meint in der Regel etwas anderes, was dann aber gar nicht rüber kommt.

[314159265358979]

cooky451 schrieb:

Da haben sie recht, aber das wird der Compiler wohl optimieren. Was halt daran liegt, dass beide Operationen auch wirklich äquivalent sind.

Wasn Schwachsinn. Soll Prozessoren geben, bei dem eine Multiplikation schneller ist.

[cooky451]

Eisflamme schrieb:

Eigentlich ist doch jede Referenz konstant, oder?

Jain. Eine Referenz kann immer nur auf das Objekt zeigen, dem sie bei der Inititalisierung zugewiesen wurde, aber du kannst eine Referenz halt nicht const qualifizieren. http://ideone.com/z692u

[Eisflamme]

Okay, aber da wir ja const als Schlüsselwort und konstant als Adjektiv voneinander entkoppelt haben, stimmt meine Aussage ja so wie ich es meine.

[SeppJ]

314159265358979 schrieb:

cooky451 schrieb:

Da haben sie recht, aber das wird der Compiler wohl optimieren. Was halt daran liegt, dass beide Operationen auch wirklich äquivalent sind.

Wasn Schwachsinn. Soll Prozessoren geben, bei dem eine Multiplikation schneller ist.

Quark, mal wieder, leider.

Optimieren heißt nicht, alle *2 pauschal durch <<1 zu ersetzen, sondern die schnellere Anweisung zu wählen.

Was ist mir dir heute eigentlich wieder los? Du bettelst geradezu darum, über das Wochenende (mal wieder) eine Pause verpasst zu bekommen.

[314159265358979]

Wenn man mal von bösen Hacks absieht, ja.

[314159265358979]

SeppJ schrieb:

Optimieren heißt nicht, alle *2 pauschal durch <<1 zu ersetzen, sondern die schnellere Anweisung zu wählen.

Was du nicht sagst.
Mir ging es auch eher um "Da haben sie recht" und "Was halt daran liegt, dass beide Operationen auch wirklich äquivalent sind.".

SeppJ schrieb:

Was ist mir dir heute eigentlich wieder los? Du bettelst geradezu darum, über das Wochenende (mal wieder) eine Pause verpasst zu bekommen.

Ahja. Dann leg mal los, wenns dir so viel Spaß macht.

[oops]

cooky451 schrieb:

Eisflamme schrieb:

Eigentlich ist doch jede Referenz konstant, oder?

Jain. Eine Referenz kann immer nur auf das Objekt zeigen, dem sie bei der Inititalisierung zugewiesen wurde, aber du kannst eine Referenz halt nicht const qualifizieren. http://ideone.com/z692u

in der form

T const &

ist die lesart einfach verkehrt: referenz auf const T.
da aber eine referenz immer auf ein objekt zeigt und immer auf das gleiche, ist es nicht unsinnig, den begriff "konstante referenz" als abkürzung für referenz auf const zu verwenden, was ja auch "const-reference" macht. wenn man allerdings nicht weiß, dass es

T & const

nicht gibt, würde es tatsächlich verwirrung machen, von const-reference oder konstanter referenz zu sprechen. referenz auf const ist in diesem fall besser, ansonsten egal.

[Nexus]

oops schrieb:

da aber eine referenz immer auf ein objekt zeigt und immer auf das gleiche, ist es nicht unsinnig, den begriff "konstante referenz" als abkürzung für referenz auf const zu verwenden, was ja auch "const-reference" macht.

Doch, "konstante Referenz" ist immer unsinnig.

"Const reference" hingegen ist völlig angebracht, sogar der C++-Standard verwendet diesen Begriff. Und er bedeutet auch nicht "konstante Referenz", das wäre nämlich "constant reference".

[oops]

Nexus schrieb:

"Const reference" hingegen ist völlig angebracht, sogar der C++-Standard verwendet diesen Begriff. Und er bedeutet auch nicht "konstante Referenz", das wäre nämlich "constant reference".

"constant reference" kann man aber genauso mit konstantenreferenz übersetzen, was genau dasselbe bedeutet, wie "const-reference", nämlich eine referenz auf eine konstante.

ich stimme dir schon zu, dass "konstante referenz" nicht eindeutig ist, eine konstanten-referenz wäre der eindeutige begriff; aber weil eine referenz immer auf das gleiche objekt verweist (und für diese definition keine wortspiele braucht), ist es absolut legitim, zu sagen "konstante referenz", wenn damit eine konstantenreferenz gemeint ist, weil aus dem kontext eindeutig klar wird, was gemeint ist.

[Nexus]

Schön, dass du mit "Konstantenreferenz" noch einen weiteren Begriff einführst, den erst recht niemand versteht :p

Wie gesagt, "const reference" ist der offizielle Ausdruck. Auf deutsch würde ich ihn mit "Const-Referenz" übersetzen. Er bezieht sich auf das Schlüsselwort const , was im Deutschen ebenfalls const ist. Es gibt sogar die Typdefinition const_reference bei Containern, die normalerweise const T& entspricht. Genauso wie bei const_iterator , das ist ja auch kein konstanter Iterator. Gleiches gilt für const_pointer . Wieso sollte es bei Referenzen plötzlich anders sein?

"Konstante Referenz" ist gerade für Anfänger unnötig verwirrend, weil der wörtliche Begriff 1. unnötige Information enthält (Referenzen sind immer konstant), 2. wichtige Information weglässt (ist das referenzierte Objekt konstant?) und 3. den Eindruck macht, dass es auch nicht-konstante Referenzen gäbe, was einfach nur falsch ist.

Während es sogar kürzer ist, "const reference" oder "Const-Referenz" zu schreiben, entspricht es auch dem im C++-Standard verwendeten Begriff und ist eindeutig. Also einigen wir uns doch bitte darauf

[oops]

Nexus schrieb:

Während es sogar kürzer ist, "const reference" oder "Const-Referenz" zu schreiben, entspricht es auch dem im C++-Standard verwendeten Begriff und ist eindeutig. Also einigen wir uns doch bitte darauf

gut, ich spreche immer gut auf das argument der kürze an

[314159265358979]

oops schrieb:

in der form

T const &

ist die lesart einfach verkehrt: referenz auf const T.

Wenn man Typen von Rechts nach Links liest, ist das absolut legitim und korrekt so.

[oops]

das "verkehrt" war nicht abwertend gemeint. das sollte einfach heißen, dass man, wenn man das so schreibt, konsistenter lesen kann (nämlich von rechts nach links (und war eine anspielung auf den anderen thread, wo es auch genau darum geht) - wenn man schreibt

const T &

ist das aber sicher "üblicher" (iSv mehr leute machen das so) und man kann es immer noch von rechts nach links lesen: referenz auf eine T-konstante. ("reference to a T-typed constant")

[pumuckl]

oops schrieb:

ist das aber sicher "üblicher" (iSv mehr leute machen das so)

Kannst du das belegen? Sprich: Statistiken über nennenswerte Projekte, die belegen, dass die "const T&" Schreibweise häufiger vorkommt als die "T const&"?
Mal abgesehen vom nicht vorhandenen Komparativ von "üblich" sollte so eine Statistik im Sinne von "üblich" natürlich eine signifikanten Unterschied zeigen, 55% zu 45% wäre z.B nicht wirklich signifikant.
So oder so sollte man als Entwickler beide Schreibweisen lesen können, eben weil sie beide begründet sind und beide vorkommen.

[314159265358979]

pumuckl schrieb:

beide begründet

Ich hätte dann gerne eine Begründung für "const T".

[Fast2_unreg]

Nexus: Ich finde den Begriff Konstantenreferenz eigentlich sehr gut, denn er füllt genau die Lücke, die es ja anscheinend gegeben hat.
T const& ist ja nichts anderes als eine Referenz auf eine Konstante

Konstante Referenz ist semantisch nicht sinnvoll, dem stimme ich zu.

pumuckl: Diese Methode zu entscheiden, was besser ist, finde ich nicht besonders sinnvoll, da sie auf eine positive Rückkopplung hinausläuft.
Zumindest mich ärgert es, dass oftmals die bekannteste, aber nicht die beste, Lösung genommen wird.

[314159265358979]

int i = 42;
int const& r = i; // Referenz auf Konstante?