Ich habe 2 Fragen zu Rückgabewerten:

1. Sagen wir ich habe eine Funktion, die eine Klasse by Value liefert:

Data getData();

Wenn ich die nun einfach so fange:

Data d = getData();

Dann wird da doch vermutlich 2mal der CopyCtor aufgerufen, oder? Einmal um das Objekt zu returnen und dann um d zu konstrieren aus dem returnten Objekt.
Wäre dann das hier performanter und empfehlenswerter?
const Data& d = getData();

2. Eine Frage zur Map. Sagen wir ich habe eine Map mit Vektoren als Value:
   map<int, vector<Foo>> m;
   Dann ist das ja ein CopyCtor Aufruf:
   Foo f = m[2];
   und das hier nicht, oder?
   const Foo& f = m[2];
   Sollte ich dann auch hier immer den Wert mit einer konstanten Referenz fangen?

const Data& getData(void);
Data foo = getData();

2. Der Feldoperator gibt auch nur eine Referenz zurück.

Abend!

Ich habe 2 Fragen zu Rückgabewerten:

1. Sagen wir ich habe eine Funktion, die eine Klasse by Value liefert:

Data getData();

Wenn ich die nun einfach so fange:

Data d = getData();

Dann wird da doch vermutlich 2mal der CopyCtor aufgerufen, oder? Einmal um das Objekt zu returnen und dann um d zu konstrieren aus dem returnten Objekt.
Wäre dann das hier performanter und empfehlenswerter?
const Data& d = getData();

Ja, dort hast du normalerweise zwei Kopien, wobei der Compiler das auch wegoptimieren kann (Stichwort (N)RVO)
Die Alternative wird vermutlich nicht funktionieren, weil du dort eine Referenz auf eine temporäre Variable anlegst, die im nächsten Moment vernichtet wird.

2. Eine Frage zur Map. Sagen wir ich habe eine Map mit Vektoren als Value:
   map<int, vector<Foo>> m;
   Dann ist das ja ein CopyCtor Aufruf:
   Foo f = m[2];
   und das hier nicht, oder?
   const Foo& f = m[2];
   Sollte ich dann auch hier immer den Wert mit einer konstanten Referenz fangen?

Ja, des wäre eine Kopie, wenn der Code funktionieren würde^* - und in dem Fall funktioniert der Ansatz mit der Referenz auch. Da kommt es halt auf deine Anwendung an, was du benötigst.

^*Deine Map enthält std::vector'en und wenn du nicht gerade einen Konstruktor Foo::Foo(const vector<Foo>&) hast, wird deine Zuweisung nicht durch den Compiler gehen.

Edit @EOutOfResources: Das funktioniert aber nur, wenn die Funktion keine lokalen Werte zurückgibt

Edit @EOutOfResources: Das funktioniert aber nur, wenn die Funktion keine lokalen Werte zurückgibt

Bei einer Funktion die mit "get" beginnt... Ansonsten gibt es da noch die Movesemantics aus C++0x:

//Hier war ein Beispiel

CStoll schrieb:

martiy2 schrieb:

Abend!

Ich habe 2 Fragen zu Rückgabewerten:

1. Sagen wir ich habe eine Funktion, die eine Klasse by Value liefert:

Data getData();

Wenn ich die nun einfach so fange:

Data d = getData();

Dann wird da doch vermutlich 2mal der CopyCtor aufgerufen, oder? Einmal um das Objekt zu returnen und dann um d zu konstrieren aus dem returnten Objekt.
Wäre dann das hier performanter und empfehlenswerter?
const Data& d = getData();

Ja, dort hast du normalerweise zwei Kopien, wobei der Compiler das auch wegoptimieren kann (Stichwort (N)RVO)
Die Alternative wird vermutlich nicht funktionieren, weil du dort eine Referenz auf eine temporäre Variable anlegst, die im nächsten Moment vernichtet wird.

Meinst du mit Alternative das hier?:

Data getData();
const Data& d = getData();

Das ist also gefährlich oder wie?

CStoll schrieb:

2. Eine Frage zur Map. Sagen wir ich habe eine Map mit Vektoren als Value:
   map<int, vector<Foo>> m;
   Dann ist das ja ein CopyCtor Aufruf:
   Foo f = m[2];
   und das hier nicht, oder?
   const Foo& f = m[2];
   Sollte ich dann auch hier immer den Wert mit einer konstanten Referenz fangen?

Ja, des wäre eine Kopie, wenn der Code funktionieren würde^* - und in dem Fall funktioniert der Ansatz mit der Referenz auch. Da kommt es halt auf deine Anwendung an, was du benötigst.

^*Deine Map enthält std::vector'en und wenn du nicht gerade einen Konstruktor Foo::Foo(const vector<Foo>&) hast, wird deine Zuweisung nicht durch den Compiler gehen.

Sorry, hab mich vertippt:/
Nur zum Verständnis. Im Map-Fall gilt:

vector<Foo> f = m[2]; // 1 CopyCtor Aufruf
const vector<Foo>& f2 = m[2]; // Garkein CopyCtor Aufruf. Performanter

Stimmt das so?

Ansonsten gibt es da noch die Movesemantics aus C++0x:

struct Data
{
  int foo;
};
struct Bar
{
  int foo;
  Data&& getData(void) const
  {
    Data Temporary;
    Temporary.foo = this->foo;
    return Temporary;
  }
};

Editier das mal schnell wieder weg, sonst kommt krümelkacker, wie es dir denn einfiehle, eine Referenz auf eine lokale Variable zurückzugeben. Eine Rückgabe von Data reicht, das Move macht der Compiler ganz automatisch.

Editier das mal schnell wieder weg, sonst kommt krümelkacker, wie es dir denn einfiehle, eine Referenz auf eine lokale Variable zurückzugeben. Eine Rückgabe von Data reicht, das Move macht der Compiler ganz automatisch.

OK.

Danke für die schnelle Antwort CStoll!

CStoll schrieb:

martiy2 schrieb:

Abend!

Ich habe 2 Fragen zu Rückgabewerten:

1. Sagen wir ich habe eine Funktion, die eine Klasse by Value liefert:

Data getData();

Wenn ich die nun einfach so fange:

Data d = getData();

Dann wird da doch vermutlich 2mal der CopyCtor aufgerufen, oder? Einmal um das Objekt zu returnen und dann um d zu konstrieren aus dem returnten Objekt.
Wäre dann das hier performanter und empfehlenswerter?
const Data& d = getData();

Ja, dort hast du normalerweise zwei Kopien, wobei der Compiler das auch wegoptimieren kann (Stichwort (N)RVO)
Die Alternative wird vermutlich nicht funktionieren, weil du dort eine Referenz auf eine temporäre Variable anlegst, die im nächsten Moment vernichtet wird.

Meinst du mit Alternative das hier?:

Data getData();
const Data& d = getData();

Das ist also gefährlich oder wie?

Ja, das ist gefährlich: Der Compiler legt eine temporäre Variable an, um den Rückgabewert aufzunehmen. Diese Variable wird am Ende der Anweisung wieder vernichtet. Wenn du eine Referenz auf diese Variable aufhebst, zeigt diese anschließend nur auf Datenmüll.
(mit NRVO spart der Compiler diese temporäre Variable ein und verwendet die lokale Variable, die aus der Funktion zurückgegeben wurde - aber die überlebt auch nicht länger)

Bei der map<> liegt der Fall ein wenig günstiger - der Index-Operator gibt eine Referenz auf das Element zurück, da überlebt das referenzierte Objekt lange genug, um damit arbeiten zu können (zumindest solange du es nicht löschst).

EOutOfResources schrieb:

CStoll schrieb:

Edit @EOutOfResources: Das funktioniert aber nur, wenn die Funktion keine lokalen Werte zurückgibt

Bei einer Funktion die mit "get" beginnt...

Auch eine get-Funktion könnte die zurückgegebenen Werte lokal berechnen

Ich frage nur deshalb, weil der CopyCtor von Data ziemlich aufwändig ist.

Ich frage nur deshalb, weil der CopyCtor von Data ziemlich aufwändig ist.

Nein. Aufwändig ist er sicher nicht! Vielleicht ist er aufwendig.

martiy2 schrieb:

Ich frage nur deshalb, weil der CopyCtor von Data ziemlich aufwändig ist.

Nein. Aufwändig ist er sicher nicht! Vielleicht ist er aufwendig.

Er wollte nur sagen, daß dazu Aufwend betrieben wird.

Er wollte nur sagen, daß dazu Aufwend betrieben wird.

martiy2 schrieb:

Ich frage nur deshalb, weil der CopyCtor von Data ziemlich aufwändig ist.

Nein. Aufwändig ist er sicher nicht! Vielleicht ist er aufwendig.

Ein kurzes googlen verrät dir: dank neuer Rechtschreibung ist der Kommentar totaler Käse.

Erst postet er schwachsinniges Zeugs,

Wo?

AmüsierterMitleser schrieb:

jetzt isser sogar zu blöd um das zu merken.

Wo?

EOutOfResources schrieb:

AmüsierterMitleser schrieb:

Erst postet er schwachsinniges Zeugs,

Wo?
Alles bis jetzt? Der falsche Tipp mit der const Referenz beim get. Der falsche Movesemantics tipp, den du nachträglich wegeditiert hast.

AmüsierterMitleser schrieb:

jetzt isser sogar zu blöd um das zu merken.

Wo?

Du hast das Posting von volkard offenbar noch immer nicht verstanden. Oh man.

Ok, dann schreibe ich also einfach
Data foo = getData();
und bete, dass der Compiler NRVO anwendet?

Ich frage nur deshalb, weil der CopyCtor von Data ziemlich aufwändig ist.

Das wäre die sinnvollste Methode. Ich erwarte eigentlich von jedem modernen Compiler, dass er die Kopie an dieser Stelle zumindest mit entsprechenden Optimierungsschaltern unterlässt und das Objekt gleich an der richtigen Stelle konstruiert.

Übrigens - nur um das richtigzustellen:

Data getData();
const Data& d = getData();

ist legaler Code. Die Zerstörung des temporären Objektes (des Rückgabewertes) wird hier verzögert, so lange die Referenz besteht. Nachzulesen im Standard, 12.2 (5). Wichtig dabei ist, dass es nur um die ursprüngliche Referenz geht. Beispielsweise kannst du nicht

struct foo {
  foo(Data const &data) : data_(data) { }
  Data const &data_;
};

foo f(getData());

schreiben, weil das temporäre Objekt nach Ende des Kopierkonstruktors - also wenn die Referenz, an die es usrprünglich gebunden wurde, seine Gültigkeit verliert - zerstört wird. Die genauen Regeln im Standard sind einigermaßen komplex, und es steht nicht zu erwarten, dass man mit diesem Trick auf neueren Compilern Laufzeit sparen kann, also kann ich diese Praxis nicht empfehlen. Gleichwohl ist sie prinzipiell erlaubt.

Irgendwie ist EOutOfResources schon extrem peinlich. Erst postet er schwachsinniges Zeugs, dann will er Klugscheißen und Rechtschreibflamen und schießt auch noch ein rießiges Eigentor und jetzt isser sogar zu blöd um das zu merken. Was für ein Clown.

Self level?
Gibt so´n Spruch mit Glashaus und Stein und so...