vector zurückgeben

Eisflamme

Dieser Artikel ist wie so oft sehr interessant:
http://en.wikipedia.org/wiki/Return_value_optimization

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

CCodex

Wenn du ein Vector zurückgeben willst must du das so machen:

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

Roger Wilco

Wie sieht es mit der Alternative aus, Smart-Pointer zu verwenden um das kostspielige Kopieren zu vermeiden?

Eisflamme

Und dafür alles auf dem Heap anlegen müssen? Pfui.

Roger Wilco

Heap = Pfui! Stack = Hui!

Kann man das so generell sagen?

asc

Roger Wilco schrieb:

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...

Roger Wilco

asc schrieb:

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.

SeppJ

Roger Wilco schrieb:

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.

Eisflamme

Da ich denke, dass die Grundfrage jetzt ganz gut beantwortet ist, würde ich gerne anreihen:

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.

Denkt ihr, der Compiler optimiert das hier noch weg?
Kann ich einfach den Model-copy-ctor privatisieren, um das zu prüfen?
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.

Roger Wilco

Eisflamme schrieb:

Denkt ihr, der Compiler optimiert das hier noch weg?

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