ist das sinnvoll oder ist es bereits übertrieben?

Gegenüber der Alternative - 'std::wstring name() const;' - hat das den Vorteil, daß eine Kopie wegfällt, was je nach Inhalt einige Zeit in Anspruch nehmen könnte.

const int& getValue() const;

besser:

int getValue() const;

okay danke. es handelt sich um eine methode in einer klasse...

Das habe ich mir schon gedacht (das letzte 'const' kann so nur innerhalb einer Klasse vorkommen)
Wichtig für die Anwendbarkeit ist aber nicht, wo die Funktion steht, sondern woher sie ihren Rückgabewert bekommt:

class test
{
  string m_name;
public:
  //so klappt_s problemlos - das übergebene Objekt lebt außerhalb der Funktion
  const string& name1() const
  {
    return m_name;
  }

  //das fliegt dir vermutlich um die Ohren (Referenz auf temporäre Variable)
  const string& name2() const
  {
    return "Mein Name ist " + m_name;
  }
};

blbalbalbal!! schrieb:

nicht übertrieben für zusammengesetzte typen. nur für fundamentale typen isses schwachsinn. z.b.

Unnötig vielleicht (bei einem int nimmt die Referenz auch nicht mehr Platz/Aufwand ein als der Wert selber), aber bestimmt kein Schwachsinn.

...

//das fliegt dir vermutlich um die Ohren (Referenz auf temporäre Variable)
  const string& name2() const
  {
    return "Mein Name ist " + m_name;
  }
};

....

Hatte ich hier nicht mal gelesen, dass der Standard das "Überleben von temporären Objekten für const&-Rückgabewerte" garantiert ? (wohl gemerkt: NUR für const-Refs, nicht für nonconst-Refs !!) .... muss mal suchen.
Hatte mich damals überrascht, aber irgendsowas habe ich in Erinnerung.

Gruß,

Simon2.

Hatte ich hier nicht mal gelesen, dass der Standard das "Überleben von temporären Objekten für const&-Rückgabewerte" garantiert ? (wohl gemerkt: NUR für const-Refs, nicht für nonconst-Refs !!) .... muss mal suchen.
Hatte mich damals überrascht, aber irgendsowas habe ich in Erinnerung.

12.2
...
5 ...
A temporary bound to the returned value in a function return statement (6.6.3) persists until the function exits.

const oder nicht-const spielt hier keine Rolle. Die Initialisierung einer Referenz auf const kann die die Erstellung eines temporären Objektes bewirken (in diesem Falle wird das temporäre Objekt durch die Addition verursacht, aber der Grund ist ohnehin egal), die Referenz wird dann an dieses temporäre Objekt gebunden. Dann wird die Lebenszeit dieses temporären Objektes aber immer noch durch obige Regel auf die Dauer der Ausführung der Funktion (das Objekt wird unmittelbar vor der Zerstörung automatischer Variablen dieser Funktion zerstört) begrenzt.

Hatte ich hier nicht mal gelesen, dass der Standard das "Überleben von temporären Objekten für const&-Rückgabewerte" garantiert ? (wohl gemerkt: NUR für const-Refs, nicht für nonconst-Refs !!) .... muss mal suchen.
Hatte mich damals überrascht, aber irgendsowas habe ich in Erinnerung.

War das nicht für temp. Objekte bei der Übergabe per Referenz?

12.2
...
5 ...
A temporary bound to the returned value in a function return statement (6.6.3) persists until the function exits.

....

LordJaxom schrieb:

...War das nicht für temp. Objekte bei der Übergabe per Referenz?

Ah !
Dann geht es eher um sowas oder ?

void f(string const& s);

int main() {
   f("Simon2"); // temporary wird erzeugt und lebt, bis f() verlassen wird

Evtl. noch für Defaultparameter ? ....

Gruß,

Simon2.

f("Simon2"); // temporary wird erzeugt und lebt, bis f() verlassen wird

Tatsächlich lebt das temporäre Objekt bis zum Ende der Auswertung des gesamten Ausdrucks, der den Funktionsaufruf enthält, nicht nur bis zum Ende des Funktionsaufrufs. Deshalb ist zum Beispiel folgendes möglich:

const string& foo(const string& s) { return s; /* s ist kein temporäres Objekt */ }
int main()
{
    cout << foo( "bar" );
// aber nicht:
    const string& s = foo( "boom" );
    cout << s; // undefiniert. s verweist nicht auf ein lebendes Objekt.
}

const string& s = foo( "boom" );
cout << s; // undefiniert. s verweist nicht auf ein lebendes Objekt.
}[/cpp]

Ganz korrekt würde das letzte Kommentar dann doch so aussehen müssen: "undefiniert. s verweist nicht MEHR auf ein lebendes Objekt".

camper schrieb:

Tatsächlich lebt das temporäre Objekt bis zum Ende der Auswertung des gesamten Ausdrucks, der den Funktionsaufruf enthält

D.h. ja das s kurzzeitig auf "boom" verweisen würde. Richtig ?

Ganz korrekt würde das letzte Kommentar dann doch so aussehen müssen: "undefiniert. s verweist nicht MEHR auf ein lebendes Objekt".

„Nicht mehr“ impliziert „nicht“ ;).

KasF schrieb:

camper schrieb:

Tatsächlich lebt das temporäre Objekt bis zum Ende der Auswertung des gesamten Ausdrucks, der den Funktionsaufruf enthält

D.h. ja das s kurzzeitig auf "boom" verweisen würde. Richtig ?

Nein. Höchstens auf ein std::string("boom"). Und darauf auch nur bei seiner Initialisierung, danach ist dieses temporäre Objekt tot.