const reference

[Halan]

Ahoi,

kurze Verständnisfrage: macht es Sinn statt einem normalen argument also zB

Code: Alles auswählen

void function(int arg);

Eine const Referenz zu benutzen, also zB

Code: Alles auswählen

void function(const int& arg);

Spar ich mir so das kopieren von Variablen? Oder wird intern ein Pointer übergeben der ja auch 32bit (bzw teilweise sogar 64bit) ist?

grüsse,
Halan

[dot]

Ja, du sparst dir das Kopieren der Variablen. Referenzen werden vom Compiler aber normalerweise über Zeiger implementiert, daher wird bei Variante 2 eben stattdessen ein Zeiger kopiert. Für primitive Typen ist sowas also sinnlos. Übliche Faustregel: Die eingebauten Typen (int, float, double, etc.) übergibt man immer by value. Übergabe als Reference to const verwendet man bei größeren Objekten. Man darf dabei halt nie vergessen, dass man den gesparten Kopieroverhead durch eine zusätzliche Indirektion erkauft.

[kaiserludi]

Dazu ist noch zu ergänzen, dass Kopien vom Compiler gut weg optimiert werden können, wenn auf sie dann doch nur lesend oder gar nicht zugegriffen wird. Auf guten Compilern kann daher sogar bei großen Objekten die Kopie schneller sein als eine Referenz (die werden meist nicht so gut wegoptimiert, so dass eben immer noch die Pointerkopie bleibt). Wenn man seinen Compiler aber nicht genau kennt, ist im Zweifel bei Objekten die Referenz zu bevorzugen, bei primitiven Typen hingegen ist quasi immer die Kopie die beste Wahl (wobei ich nie geteste habe, ob es was bringt, z.B. einen long double auf einem 16bit System lieber zu referenzieren, bevor es auf die paar byte ankäme, gibts meist viel effektiveres in der High-Level Logik zu optimieren).

[Krishty]

Dazu ist noch zu ergänzen, dass Kopien vom Compiler gut weg optimiert werden können, wenn auf sie dann doch nur lesend oder gar nicht zugegriffen wird. Auf guten Compilern kann daher sogar bei großen Objekten die Kopie schneller sein als eine Referenz.

Aber nur, falls die Kopie keine globale Wirkung hat. Übergäbe man einen std::vector by Value, wären da ein new [] und delete [] drin, und das würde kein Compiler der Welt wegoptimieren. Darum würde ich es 1. nur mit POD machen und 2. nur, falls ich weiß, dass mein Compiler keine zuverlässige Aliasing-Analyse durchführen kann (also nicht bei Visual C++ mit LTCG).

[dot]

Das hängt davon ab. Wenn der Funktion ein Temporary übergeben wird, dann darf der Compiler wegoptimieren, selbst wenn die Kopie Seiteneffekte hätte.

[Krishty]

Wow, das wusste ich nicht. Paragraph?

[dot]

§12.8 Absatz 32, besser bekannt unter den Namen Copy Elision und RVO. Afaik machen das auch praktisch alle Compiler heutzutage. MSVC machts, grad ausprobiert:

Code: Alles auswählen

#include <iostream>

class B
{
public:
  B()
  {
    std::cout << "B" << std::endl;
  }

  B(const B& b)
  {
    std::cout << "B copy" << std::endl;
  }

  ~B()
  {
    std::cout << "~B" << std::endl;
  }
};


void foo(B b)
{
}

int main()
{
#if 0
  B b;
  foo(b);
#else
  foo(B());
#endif
}

Interessanter Artikel dazu: http://cpp-next.com/archive/2009/08/wan ... -by-value/ ;)

[Krishty]

Wieder was gelernt.

Warum sagen eig alle „Seiteneffekte“? Ich warte echt darauf, dass „Bei Risiken und Seiteneffekten“ in der Medikamentenwerbung landet … ;-)

[dot]

Warum sagen eig alle „Seiteneffekte“?

Na weil man eben so sagt :P

[Artificial Mind]

Warum sagen eig alle „Seiteneffekte“?

Na weil man eben so sagt :P

Na weil man eben im Englischen "side effects" sagt und einige/viele Deutsche nicht mitbekommen haben, dass es mit "Nebeneffekten" übersetzt wird :P

[BeRsErKeR]

Wohl eher "Nebenwirkungen" ...

[Halan]

Ja, du sparst dir das Kopieren der Variablen. Referenzen werden vom Compiler aber normalerweise über Zeiger implementiert, daher wird bei Variante 2 eben stattdessen ein Zeiger kopiert. Für primitive Typen ist sowas also sinnlos. Übliche Faustregel: Die eingebauten Typen (int, float, double, etc.) übergibt man immer by value. Übergabe als Reference to const verwendet man bei größeren Objekten. Man darf dabei halt nie vergessen, dass man den gesparten Kopieroverhead durch eine zusätzliche Indirektion erkauft.

Danke. Das ist genau das was ich wissen wollte. Hast meine Vermutung bestätigt :)

[Artificial Mind]

Wohl eher "Nebenwirkungen" ...

http://dict.leo.org/ende?lp=ende&search=side-effect ...

[BeRsErKeR]

Wohl eher "Nebenwirkungen" ...

http://dict.leo.org/ende?lp=ende&search=side-effect ...

Ich glaube Nebenwirkung ist weitaus gebräuchlicher als Nebeneffekt. Und ich bezog mich da auch eher auf Krishtys Aussage mit den "Risiken und Seiteneffekten" auf Packungsbeilagen. ;)

[Artificial Mind]

Im Kontext der Medikamentenwerbung gebe ich dir Recht ;)

[Chromanoid]

Hehe http://de.wikipedia.org/wiki/Seiteneffekt ist dazu ganz witzig zu lesen.

[dot]

Ich find ehrlich gesagt, dass "Seiteneffekt" ein sehr viel besser Name ist als "Nebenwirkung"...