vector<T>& Access()
	{
		return data;
	}

Eigentlich will ich nur, dass man in jedem Fall eine Referenz zurückbekommt. So wie das jetzt ist, kann man sich das scheinbar aussuchen ob man eine Kopie oder eine Referenz will:

vector<MeinT> vec = klasse.Access();  // Lokale Kopie
vector<MeinT> &vec = klasse.Access();  // Referenz

Ist das richtig so, ich finde das gerade sehr merkwürdig?!?

Übrigens, jeder gute Compiler kann Kopien von Objekten weg optimieren! Also, keine Referenz zurück geben!

Und lokale Variablen, gibt man auch nicht als Referenz zurück. Dürfte auch jeder vernünftige Compiler eine Warning ausspucken.

Einfach mal im Netz oder hier im Forum nach RVO suchen.

Man sollte niemals Membervariablen als Referenz zurück geben.

Das würde ich nicht auf Const-Referenzen verallgemeinern (ich bin mir nicht sicher, ob du dich nur auf Referenzen auf unqualifizierte Objekte bezogen hast).

Auch mit der Optimierung ist das nicht immer so einfach. Die Chancen auf RVO stehen gut, wenn es sich um funktions-lokale Variablen handelt - bei Membervariablen hingegen weniger.

Artchi schrieb:

Man sollte niemals Membervariablen als Referenz zurück geben.

Das würde ich nicht auf Const-Referenzen verallgemeinern (ich bin mir nicht sicher, ob du dich nur auf Referenzen auf unqualifizierte Objekte bezogen hast).

Hmm. Ich schon.
Wenn die Referenz const ist, dann kannst du zwar den Inhalt nicht verändern, aber du hast immer noch Zugriff auf etwas, was eigentlich privat ist. Was ist, wenn jetzt eine Member des Objektes halt nicht genau so zurückgegeben werden soll, wie sie drin steht? - Also z.B noch ein Offset oder so dazu kommt. Das hast du mit einem getter voll unter Kontrolle, aber mit einer zurückgegeben Referenz nicht. Da müsstest du dann im Nachhinein das zurück gegebene Objekt nur noch als Proxy benutzen, und das eigentliche Objekt, das es mal war anderst benennen und dann das eigentliche, sowie das Proxy Objekt halten, welches dann auch immer die aktuellen Daten halten muss und kann sie nicht erst berechnen, wenn sie wirklich abgefragt wird.

Meine Meinung zu Kapselung.

Was ist, wenn jetzt eine Member des Objektes halt nicht genau so zurückgegeben werden soll, wie sie drin steht? - Also z.B noch ein Offset oder so dazu kommt. Das hast du mit einem getter voll unter Kontrolle, aber mit einer zurückgegeben Referenz nicht.

Aber es geht doch gerade um den Rückgabetyp eines getters?

mytype const& get_member_ref(unsigned offset) const { return myData[offset]; }

So kann der Aufrufer entscheiden, ob er eine Kopie will, auf die er dann auch schreiben kann, oder eine Nur-Lesen-Referenz, wo garantiert nichts kopiert wird.
Oder verstehe ich dich falsch?

Dann musst du so etwas machen:

mytype const& foo::get_member_ref(unsigned offset) const 
{ 
  mytype temp = myData[offset];
  temp.x + 0.1f; // oder sonst was
  return temp; 
}

Was ja offensichtilch böse ist. Also so etwas:

class foo
{
  ...
private:
 mytype myData[COUNT];
 mytype myData_offsets[COUNT];
};

mytype const& get_member_ref(unsigned offset) const 
{ 
  return myData_offsets[offset];
}

Und hier darfst du, soblad sich myData ändert auch noch schauen, dass myData_offsets auch aktuell ist.

Und, wie du selber schon vermutest, ist das nicht so das wahre.
Es gibt natürlich Ausnahmen, wo sowas Sinn macht, aber nicht wenn man es vermeiden kann. (siehe z.B std::string::c_str() ).

In dem Fall würde man das Interface natürlich ändern. Macht aber nichts, weil man eine Referenz an den Rückgabewert einer Funktion binden kann und diese Referenz im aufrufenden Scope gültig bleibt.

mytype foo::get_data(unsigned offset) const // interface wurde geändert, vorher wars eine const-ref, jetzt ist es eine kopie
{
  mytype temp = myData[offset];
  temp.x + 0.1f;
  return temp;
}

int main()
{
    mytype const& data = bar.get_data(42); // aufruf hat sich trotz interface-änderung nicht geändert
    std::cout << data; // gültig
}

AFAIK ist das erlaubt!?
Ich würde aber Referenzen sowieso nur dann zurückliefern, wenn ich solche Änderungen sicher ausschließen kann.

int main()
{
    mytype const* data = &(bar.get_data(42));
    std::cout << *data; // hups
}

Natürlich kann man hier jetzt argumentieren, dass der User dann selbst Schuld ist, aber man sollte dieses Riskiko nur eingehen, wenn man es wirklich braucht. Und das ist nicht der Fall, wenn man Angst vor Kopien hat.

Ich zumindest versuche Getter-Funktionen - egal welchen Rückgabetyps - möglichst allgemein anzuwenden. Also nicht etwa die Const-Referenz lange zwischenzuspeichern oder so. Meist benutze ich den zurückgegebenen Wert gleich in einem temporären Ausdruck, damit er sicher noch existiert, oder ich erstelle eine lokale Kopie, um die Lebensdauer zu verlängern. Eine Kopie kann man ja immer noch erstellen, aber man wird nicht dazu gezwungen, wenns nicht nötig ist. Wenn ich selber etwas schreibe, erwarte vom Benutzer aber auch, dass er nicht irgendwelche Annahmen bezüglich Lebensdauer oder Gültigkeit trifft, wenn eine Referenz im Spiel ist. Im Zweifelsfalle sollte man sowieso die Dokumentation anschauen. Und solange man Const-Referenz-Rückgabetypen keine besondere Behandlung zukommen lässt, ist es auch kein Problem, die Schnittstelle falls nötig doch zu einer Kopie zu ändern (nur rekompilieren). Allerdings habe ich bisher fast nie solche Änderungen durchführen müssen.

Ein ganz anderes Argument: Bei einigen Typen ist eine Kopie aus semantischen Gründen nicht angebracht - vielleicht, weil sie gewisse Seiteneffekte mit sich bringt - oder weil das Objekt schlicht und einfach nicht kopierbar ist.

Also zusammengefasst: Ich bin nicht der Meinung, dass Const-Referenzen die Kapselung grundsätzlich verletzen. Ich wäge den konkreten Fall ab; dabei spielt ein Rolle, wie gross das zurückgegebene Objekt ist, wer den Code benutzt oder wie wichtig Geschwindigkeit jeweils ist.