[C++] Scope van temp object?

[DieterVDW]

Beste GoT'ers,

Klein vraagje, zie onderstaand stukje code:

code:

class SomeObject {
    public:
        std::string toString() const {
             return "string by value";
        }
}

...
SomeObject o;
const char* cStr = o.toString().c_str();
std::cout << cStr << std::endl;
...

Zit er een memory leak in die laatste 3 regels ja of nee?
Maw: wat is de scope van het temp std::string object dat verkregen wordt als resultaat van de o.toString() call?
Bevat de cStr variabele nog een geldige pointer bij het uitprinten?

Ik vermoed dat het volgende gebeurt:
1. std::string wordt teruggegeven by value door o.toString(), dus temp variabele
2. Er wordt een pointer naar de interne string bytes teruggegeven door c_str()
3. Na die lijn wordt de std::string gedealloceerd, en wijst de cStr pointer naar vrijgegeven geheugen.

Juist of niet?

[remco_k]

DieterVDW schreef op dinsdag 08 maart 2011 @ 14:24:
3. Na die lijn wordt de std::string gedealloceerd, en wijst de cStr pointer naar vrijgegeven geheugen.

Ja.
Na regel 10 wijst de cStr pointer naar een ongeldig adres omdat "std::string toString()" out of scope is geraakt en zichzelf heeft opgeruimd, terwijl jij de pointer (cStr) nog hebt naar zijn vroegere adres waar hij z'n string had staan. Daar kan nog steeds dezelfde string staan. Of beschadigd, of helemaal niet. Hoe dan ook: deze pointer nog gebruiken is niet goed.

[ Voor 35% gewijzigd door remco_k op 08-03-2011 14:41 ]

[EddoH]

Een temporary object op deze manier wordt gedealloceerd aan het eind van de expressie. In dit geval heb je dus een dangling pointer.

[DieterVDW]

Alright, bedankt! Dit vermoedde ik al.
Dikke vette dangling pointer gevonden in onze applicatie dus. Excellent!

[MSalters]

Een dangling pointer is overigens het tegenovergestelde van een memory leak. In het eerste geval heb je wel een pointer maar geen memory, in het tweede geval memory zonder pointer.

[.oisyn]

De lifetime van een temporary kun je trouwens verlengen naar het einde van de scope als je 'm aan een reference bindt. Hier niet erg van belang, je kunt de temporary ook gewoon kopiëren naar een lokaal object. Maar als dat niet mogelijk is (omdat het object bijv. noncopyable is), dan kun je 'm op die manier toch langer houden.

[ Voor 47% gewijzigd door .oisyn op 09-03-2011 00:00 ]

[Gehakt]

Zolang er niks met dat stukje geheugen gebeurt kan die dangling pointer trouwens heel lang goed gaan. Echter zodra je programma besluit om daar iets anders neer te zetten kan je pointer naar een compleet andere waarde wijzen.
Daarom zijn ze niet altijd even makkelijk te vinden. Op regel 11 gebruik je cStr direct na deallocatie waardoor de waarde die daar in het geheugen staat hoogstwaarschijnlijk nog hetzelfde is als daarvoor.

[ Voor 32% gewijzigd door Gehakt op 09-03-2011 00:26 ]

[DieterVDW]

Mja, in de praktijk genereerde dat ongeveer 1 op de 10 keer een fout... Compleet random.
Vrij vervelend, en lastig om te debuggen. Lang leve Valgrind!