Parameter als Referenz übergeben unnötig?

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

Ich möchte einfach gerade nur herausfinden, wie wichtig es ist, den Code selber zu optimieren, und was der Compiler/Linker von sich aus schon optimiert. z.B. schlagen einige Leute vor, dass Bit-Schiebe-Operationen schneller seien als das multiplizieren mit einer 2er-Potenz. Oder das Benutzen von inline-Funktionen. Mir fehlt da der Durchblick...

[quote="Gugelmoser"]

Dicker schrieb:

Wenn ich einen Parameter als konstante Referenz kennzeichne

Es gibt keine konstanten Referenzen, nenne sich bitte const-reference.
Was ist denn das fuer ein Schwachsinn?

cooky451

Dicker schrieb:

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

Fakt bleibt aber, dass der Code einfach eine andere Bedeutung bekommt. Eine const& und eine Kopie sind eben nicht genau das Gleiche, auch wenn sie teilweise dem gleichen Zweck dienen können.
Faustregel:
<= 8 Byte -> Kopie
> 8 Byte / Unbekannt -> const&
Und in Kopierkonstruktoren brauchst du z.B. immer eine const&.

Dicker schrieb:

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

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

Dicker schrieb:

Oder das Benutzen von inline-Funktionen. Mir fehlt da der Durchblick...

Das benutzt man eigentlich nur noch, wenn man freie Funktionen im Header definiert, damit der Linker sich nicht beschwert. Es ist halt ein Tipp an den Compiler, aber nach meiner Erfahrung wird der meistens ignoriert.

Edit:

SonQuatsch schrieb:

Was ist denn das fuer ein Schwachsinn?

LOL, dann zeig uns doch mal eine konstante Referenz.

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.

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

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

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.

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.