vector<T> foo()
{
  vector<T> bar;
  // tue was mit bar
  return bar;
}
vector<T> bar = foo();

ist das langsamer als

void foo(vector<T>& bar)
{
 // tue was mit bar
}
vector<T> bar;
foo(bar);

?

Für die lange Antwort: Such mal nach "return value optimization".

Anscheinend sollten wir also bei komplizierteren/bedingten Erzeugungen von Objekten nicht den RV nehmen, bis 0x kommt.

std::vector<std::string> abc(std::string abc)
{
//irgend was
}

Heap = Pfui! Stack = Hui!

Kann man das so generell sagen?

Heap = Pfui! Stack = Hui!

Kann man das so generell sagen?

Nicht generell, aber ich würde grundsätzlich erst einmal Programme möglichst leicht verständlich schreiben (was die Thematik Zeiger zumindest etwas reduziert), und dann schauen was langsam ist und ggf. angepasst gehört.

Gerade in Hinblick auf den kommenden Standard hoffe ich das dieses Thema in Zukunft weitaus unproblematischer sein wird. Ganz davon abgesehen das auch C++ nicht den Heap ausschließt, sondern häufig nur etwas kapselt...

Nicht generell, aber ich würde grundsätzlich erst einmal Programme möglichst leicht verständlich schreiben (was die Thematik Zeiger zumindest etwas reduziert), und dann schauen was langsam ist und ggf. angepasst gehört.

Hmm. Ich dachte immer, Heap vs. Stack wäre mehr eine Frage der Objektgröße.

Hmm. Ich dachte immer, Heap vs. Stack wäre mehr eine Frage der Objektgröße.

Das ist eher der technische Grund. Aber dafür kann (und sollte) man große Objekte ja so bauen, dass sie selber ihren Speicher auf dem Heap selber anlegen und verwalten.

Der programmiertechnische Unterschied, und darauf kommt es an, ist die Lebensdauer der Objekte. Bei Stackobjekten muss man sich in der Regel um nichts kümmern weil alles automatisch geht, dafür kann man aber einige bestimmte Sachen nicht machen. Bei Sachen auf den Heap hat man die volle Kontrolle, aber auch die volle Verantwortung.

Ich habe jetzt tatsächlich eine recht aufwendige Factory-Methode.

Genauer: Ich implementiere eine Art Factory Pattern. Eine Basisklasse hat eine Methode:

virtual Model LoadModel(const string& filename) // ich weiß, ich nerve mit meinem Model-Gedöns :P

Diese ruft einer der LoadModel-Methoden ihrer Kinder auf, je nachdem, was der Benutzer gerade braucht (das Model kann mit verschiedenen Loadern geladen werden).

Jedenfalls sieht eine LoadModel-Methode tatsächlich so aus:

{
Model newModel;

func1(newModel);
func2(newModel);
func3(newModel);
// ...

return newModel;
}

funci seien private Methoden void funci(const Model&), welche alle für sich was am Model rumbasteln.

Die LoadModel-Methode ist ja recht schlicht, bis auf die Aufrufe der anderen Methoden. Der Benutzer meines Spiels sollte natürlich nicht unbedingt lange warten und wenn hunderte von Modellen geladen werden, kann das selbstverständlich schon etwas dauern.

1. Denkt ihr, der Compiler optimiert das hier noch weg?
2. Kann ich einfach den Model-copy-ctor privatisieren, um das zu prüfen?
3. Welche Alternative würdet ihr sonst nehmen, um die copy-ctor-Aufrufe zu vermeiden? Den Benutzer der Load-Klasse selbst ein Model erstellen lassen und es füllen a la:

Model m;
modelLoader.LoadModel("wurst.3ds", m);

mit dem zweiten LoadModel-Parameter als Referenz? Wäre jetzt für mich das einzig Sinnvolle.

1. Denkt ihr, der Compiler optimiert das hier noch weg?
2. Kann ich einfach den Model-copy-ctor privatisieren, um das zu prüfen?

Vielleicht einfach testen und im Kopierkonstruktor eine Debug-Ausgabe erzeugen.
Edit:
Evtl. hilft auch dieser Thread von Nexus weiter: http://www.c-plusplus.net/forum/viewtopic-var-t-is-273296.html