Halbwegs aktuelle Compiler können RVO!
Der ReturnWert-Übergabe ist IMHO auch ned das performance Problem.
Das "Problem" ist die Allokierung des Rueckgabewertes, und die eventuelle dynamische vergroesserung des Buffers.
Linderung schafft, indem man nicht mit trivialen
allokiert, sondern erst dann wenn man scho weiss wie gross das teil wird und dann scho mit der entsprechenden groesse initialisiert
Aber in diesem Fall wird es einfach zu kompliziert und fehleranfällig.
Definitiv.
Aber, ich sag immer wieder, wenn man niemals in nem Programm "Schmutz", "Hacks" oder andere wilde Dinge macht, um der Performance zu genügen, sollte man sich aber auch fragen, ob C++ die richtige Sprache an der Stelle war
Das heisst nicht, das man in C++ nicht sauber und sicher auf Kosten der Performance programmieren soll ... das sollt auch in C++ die Regel sein.
Aber trotzdem sollt man sich der Performance-Thematik bewusst sein und auch bewusst die Entscheidung gegen die Performance treffen. Dann weiss man auch sofort, wo und wie man im entsprechenden Falle optzimieren koennt.
ch würde dann aber immer noch versuchen, die Optimierungen hinter einem einfach benutzbaren Interface zu verstecken.
Und genau das geht dann meistens nicht ... weil das Interface selber schon das performance Problem darstellt.
Biespiel:
Ich analysiere hier zur Laufzeit Datenstroeme mit Geschwindigkeiten um die 50Mbit .
Manche Werte ergeben halt Texte (ASCII).
wuerde Irgendwein Interface so aussehen
std::string IClass::getValue() const;
waer ich mit der Performance am Arsch ^^
Meine groessten feinde sind die news und die allokatoren ...
Und ich hab grad hier arg Probleme mit anderen Programmierkollegen.
Ich krieg interface's vorgesetzt, mit denen kann ich allein schon wegen dem Interface nimmer performant sein.
Performance faengt leider auch schon mit dem Design des Interfaces an ...
Aber davon denk ich, is der TE noch weit entfernt.
Trotzdem sollt man von Anfang an scho bissi in die Richtung denken, und lernen sich bewusst zwischen Performance und Sicherheit und Wartbarkeit entscheiden, und diese Entscheidung auch tragen. Das begleitet einen seinen ganzen Weg als Programmierer.
Und obwohl ich mit Leib und Seele C++ Programmierer bin, und Scriptjunkies belaechele
solange ich in der Firma bin, muessen sich meine Kollegen die Frage gefallen lassen: "Und warum qt / c++ ? Das haett man doch in Java / Python schneller und saueberer hinbekommen ?"
Ciao ...