[C++] copy overhead vermijden bij return value

[Bob]

Ik wil de return data van een functie zonder onnodige stack copies in een vector duwen, en dacht hiervoor een reference variable te gebruiken. Zie hieronder.
Bestaat er geen cleanere oplossing? Ik heb het gevoel dat ik hier onnodige omwegen neem.
(ik duw het niet onmiddellijk in de vector omdat ik nog even doStuff wil aanroepen zonder in de vector te moeten gaan)

C++:

#include <vector>

using std::vector;

class HugeObj{
public:
    HugeObj(unsigned int i = 0) : i_(i){}
    void doStuff() { /* ... */}
private:
    unsigned int i_;
};

HugeObj produce(unsigned int i){
  return HugeObj(i);
}

int main(int argc, char* argv[])
{
    HugeObj& current = HugeObj();
    vector<HugeObj> storage;
    unsigned int i = 0;
    while(i!=100){
        current = produce(i);
        current.doStuff();
        storage.push_back(current);
        ++i;
    }
}

[StM]

Waarom maak je je object niet dynamisch aan en geef je hem de pointer?

edit: ik zie je wel meer rare dingen doen. Ga je eens inlezen op pointers.

[ Voor 35% gewijzigd door StM op 04-11-2009 15:34 ]

[NC83]

Een C++ compiler zal in dit geval als optimalisaties aan staan hier al geen kopie teruggeven.

C++:

HugeObj produce(unsigned int i){ 
  return HugeObj(i); 
} 

Trouwens waarom bestaat die produce funtie in dit geval, of is dat normaal een factory functie die daar wordt gebruikt. En zo ja dan zou je daarvan altijd al een pointer naar een base class willen terug geven. Normaal vermijd je een kopie aanmaken door een const reference of een pointer uit een functie terug te geven.

[Bob]

Site.to.Make schreef op woensdag 04 november 2009 @ 15:32:
Waarom maak je je object niet dynamisch aan en geef je hem de pointer?

edit: ik zie je wel meer rare dingen doen. Ga je eens inlezen op pointers.

Ik weet hoe pointers werken, maar wilde in dit geval een oplossing zonder pointers proberen te maken. Kwestie van later niet meer te moeten destructen.

NC83 schreef op woensdag 04 november 2009 @ 15:36:
Een C++ compiler zal in dit geval als optimalisaties aan staan hier al geen kopie teruggeven.

C++:

HugeObj produce(unsigned int i){ 
  return HugeObj(i); 
} 

Trouwens waarom bestaat die produce funtie in dit geval, of is dat normaal een factory functie die daar wordt gebruikt. En zo ja dan zou je daarvan altijd al een pointer naar een base class willen terug geven. Normaal vermijd je een kopie aanmaken door een const reference of een pointer uit een functie terug te geven.

produce is hier slechts een artificieel voorbeeld, in mijn echte code doet die uiteraard iets nuttigs (een vector met een reeks pointers produceren om precies te zijn)
Maar als de compiler het optimaliseert is het natuurlijk ook goed, dan moet ik niet zo knoeien.

[.oisyn]

NC83 schreef op woensdag 04 november 2009 @ 15:36:
Een C++ compiler zal in dit geval als optimalisaties aan staan hier al geen kopie teruggeven.

C++:

HugeObj produce(unsigned int i){ 
  return HugeObj(i); 
} 

Daar wel ja, maar dat is het punt niet. De push_back() zal sowieso resulteren in een kopie.

C++:

#include <iostream> 
#include <vector>

using namespace std; 

struct Foo
{
    Foo() { std::cout << "Foo()" << std::endl; }
    Foo(const Foo &) { std::cout << "Foo(const Foo &)" << std::endl; }
};

Foo CreateFoo()
{
    return Foo();
}

int main (int argc, char * const argv[])
{
    const Foo & foo = CreateFoo();
    std::vector<Foo> v;
    v.push_back(foo);
}

Output:

Foo()
Foo(const Foo &)

Zelfs als je push_back(Foo()) doet hou je nog steeds het probleem, gezien de interne werking van std::vector (typisch een new(ptr) T(copy), met 'ptr' een pointer naar waar het object moet komen en 'copy' het argument van push_back()).

C++0x fixt hier wat issues mee. Ten eerste heb je emplacement construction waardoor je direct een T kunt constructen *in* de container, ipv er een naartoe te kopieëren. Daarnaast heb je r-value references, waardoor je goedkoop geheugen kunt moven van het ene object naar het andere.

@Bob: er zit trouwens een fout in regel 19. Je mag een temporary niet aan een non-const reference binden. MSVC++ laat dit weliswaar toe, maar het is foute C++ code.

Overigens moet je niet vergeten dat vector al helemaal een slechte container is als het kopieëren van de objecten die je erin stopt duur is. Een vector zet alle objecten namelijk achter elkaar in het geheugen. Als je er een object aan toevoegt terwijl dat niet meer past (capacity() == size()), zal hij een nieuwe grotere buffer moeten alloceren en alle oude contents naar de nieuwe moeten kopieëren, waardoor hij dus elk object in de vector gaat copy constructen. Als je de eigenschappen van een vector wilt behouden, kun je het beste een vector van (smart)pointers gebruiken. Dan is een resize goedkoop, en hoef je ieder object maar 1 keer te constructen.

[ Voor 34% gewijzigd door .oisyn op 04-11-2009 16:13 ]

[Soultaker]

Ja, de compiler is expliciet toegestaan om een temporary object helemaal weg te optimaliseren (zelfs als dat de werking van het programma verandert!) Dat staat bekend als Return Value Optimization.

In jouw code betekent dat dat de assignment op regel 23 weggeoptimaliseerd kan worden (ook al is produce ingewikkelder). Wellicht wordt er op regel 25 dan alsnog een kopie gemaakt om het object daadwerkelijk op te slaan in de vector (dat hangt af van de implementatiedetails, maar ik vermoed dat die kopie onvermijdelijk is, omdat op dat punt zowel current als storage[i] een kopie moeten bevatten, en aangezien geen van beide temporaries zijn, kun je er niet eentje weghalen).

Tenslotte zit er een fout in je voorbeeldcode, want regel 19 kan niet: als current een reference variable is, dan kun je 'm niet initialiseren met een temporary (want die levert een const reference op). Ik weet niet hoe je zo op deze code gekomen bent; als je in je echte code wel met een reference variable werkt, gaat het hele verhaal in deze thread niet op.

[.oisyn]

Soultaker schreef op woensdag 04 november 2009 @ 16:02:
In jouw code betekent dat dat de assignment op regel 23 weggeoptimaliseerd kan worden (ook al is produce ingewikkelder).

Nee, dat kan dus niet. 'current' is namelijk al geconstruct, en dus resulteert het hoe dan ook in een operator=(). Als je echt van RVO gebruik wilt maken zul je het resultaat van de functie moeten binden aan een object wat je aan het constructen bent, dus "HubeObj current = produce(i);".

[Bob]

Soultaker schreef op woensdag 04 november 2009 @ 16:02:


Tenslotte zit er een fout in je voorbeeldcode, want regel 19 kan niet: als current een reference variable is, dan kun je 'm niet initialiseren met een temporary (want die levert een const reference op). Ik weet niet hoe je zo op deze code gekomen bent; als je in je echte code wel met een reference variable werkt, gaat het hele verhaal in deze thread niet op.

Gek, het compileert en runt zonder troubles.
Vanuit het standpunt van de compiler kan het (volgens mijn basic compiler kennis) toch?
Object (temporary) wordt op de stack gemaakt.
Reference variable wordt er aan gehangen, het object heeft dus plots een 'touwtje'. (symbol?)
Wanneer current out of scope gaat kan het object nog steeds gedestroyed worden.

Op die manier zie ik geen probleem, maar als jullie beiden zeggen dat het niet kan/mag, zal mijn visual c++ compiler hier dingen doen die niet mogen...

Voor de volledigheid, heb de code nog wat uitgebreid om het probleem verder te testen, het compileert en runt.

C++:

#include <vector>
#include <iostream>

using std::vector;
using std::cout;
using std::endl;

class HugeObj{
public:
    HugeObj(unsigned int i = 0) : i_(i){}
    void doStuff(){cout << i_ << endl;}
    void setI(unsigned int i){i_ =i;}
private:
    unsigned int i_;
};

HugeObj produce(unsigned int i){
  return HugeObj(i);
}

int main(int argc, char* argv[])
{
    HugeObj& current = HugeObj();
    current.setI(3);

    vector<HugeObj> storage;
    unsigned int i = 0;
    while(i!=100){
        current = produce(i);
        current.doStuff();
        storage.push_back(current);
        ++i;
    }
}

[.oisyn]

Zoals ik al zei, MSVC++ laat het toe, maar het mag officieel niet. Erg veel nut heeft het trouwens ook niet, je code is equivalent als je de reference weghaalt.

[ Voor 41% gewijzigd door .oisyn op 04-11-2009 16:34 ]

[Bob]

.oisyn schreef op woensdag 04 november 2009 @ 16:31:
Zoals ik al zei, MSVC++ laat het toe, maar het mag officieel niet.

Ik ga weer op leescursus.

[.oisyn]

Ik had het er later bij-geëdit, wellicht stond het er nog niet bij toen jij m'n post las

[Bob]

.oisyn schreef op woensdag 04 november 2009 @ 16:38:
Ik had het er later bij-geëdit, wellicht stond het er nog niet bij toen jij m'n post las

Zo doen we dat dus ...

Verder (ik zou beter m'n werk afmaken maar goed, ik leer hier nuttige dingen): wat bedoel je juist met de code is niet nuttig met die reference? In geval van optimalisatie is het wslk niet nuttig nee, bedoel je dat?

[.oisyn]

Ik bedoel dat de reproduceerde assembly waarschijnlijk 100% identiek is. In beide gevallen leeft 'current' op de stack in de functie main(). In de variant met reference is het een temporary waar je een referentie naar hebt genaamd 'current' (waardoor die temporary de lifetime van 'current' meekrijgt), maar omdat de compiler weet waar dat ding op de stack staat en waar de reference naar wijst zal 'current' zich dus net zo gedragen als het geen reference was geweest.

Het is niet dat je op regel 29 de reference naar iets anders laat wijzen, want dat kan namelijk niet. Een reference laat je alleen bij construction naar iets wijzen, en vanaf dat moment doet het net alsof je tegen het object zelf praat. Op regel 29 krijg je dus gewoon een assignment aan de temporary die je op regel 23 gemaakt hebt.

[Bob]

Nu ben ik weer helemaal mee. Mijn poging om het effect van rvalue references te verkrijgen sloeg dus nergens op, en is hier ook niet eens nodig bij de lijn current = produce(i);, omdat de compiler het beter kan ...

[NC83]

Als je het wel naar iets anders wil laten wijzen zul je dus een pointer moeten gebruiken. Daarnaast als je je vector dan declreert om pointers naar hugeObj's te bevatten wordt de overhead van de vector al een stuk minder.

Hou er wel rekening mee dat als je de vector leeg maakt je eerst de objecten opruimte en dan pas vector.clear of swap doet met een lege vector.

[.oisyn]

Of je gebruikt std::vector<std::tr1::shared_ptr<HugeObj>>, dan worden objecten automatisch opgeruimd . Maar een std::list<HugeObj> is handiger als je geen random access container nodig hebt.

[ Voor 29% gewijzigd door .oisyn op 04-11-2009 17:04 ]

[Soultaker]

.oisyn schreef op woensdag 04 november 2009 @ 16:11:
Nee, dat kan dus niet. 'current' is namelijk al geconstruct, en dus resulteert het hoe dan ook in een operator=(). Als je echt van RVO gebruik wilt maken zul je het resultaat van de functie moeten binden aan een object wat je aan het constructen bent, dus "HubeObj current = produce(i);".

Hmm, ik had uit de losse pols geredeneerd dat current dan gedestruct zou worden voor de call, maar dat werkt natuurlijk niet zo. De (hier impliciete) assignment operator wordt gecalld, niet de copy constructor.

Re: vectors: als je in het echt (zoals in je voorbeeld) weet hoeveel elementen in je vector gaat stoppen kun je natuurlijk eerst genoeg ruimte reserveren (met reserve() of resize()) dat scheelt al de helft van het probleem. Verder zou ik me in 't algemeen niet zo druk maken om dit soort optimalisaties, eerlijk gezegd.

[ Voor 21% gewijzigd door Soultaker op 04-11-2009 17:11 ]

[farlane]

Soultaker schreef op woensdag 04 november 2009 @ 17:09:
Verder zou ik me in 't algemeen niet zo druk maken om dit soort optimalisaties, eerlijk gezegd.

Zijn keuze voor de naam HugeObj suggereert dat het wel relevant is.

[Zoijar]

.oisyn schreef op woensdag 04 november 2009 @ 16:58:
Of je gebruikt std::vector<std::tr1::shared_ptr<HugeObj>>

Dat lijkt mij verreweg de beste oplossing en is iets dat ik zelf ook altijd doe.

C++ mantra: every problem can be solved by an extra layer of wrapping.

[ Voor 12% gewijzigd door Zoijar op 04-11-2009 19:07 ]

[farlane]

Zoijar schreef op woensdag 04 november 2009 @ 18:52:
C++ mantra: every problem can be solved by an extra layer of wrapping.

... except too many layers of wrapping ?

[Zoijar]

farlane schreef op woensdag 04 november 2009 @ 21:11:
[...]

... except too many layers of wrapping ?

Nee, dat is het grappige: je hebt nooit te veel layers of wrapping