[C++] Denkfout??

[^Mo^]

Ik ben bezig een dll aan het maken, maar nu zit ik met een denkfout.... tenminste, dat denk ik. Ik heb een globale lijst van objecten van een bepaalde class, en deze declareer ik ook een paar keer extern in andere files. Nu is het zo dat bij het ontladen van de dll de lijst niet goed wordt opgeruimd, er blijft dus gealloceerd geheugen hangen... Het is toch zo dat als ik iets globaal declareer, en het programma stopt (of dll ontlaadt) dat het object dan opgeruimd wordt...? Ik maak nu overigens de lijst expliciet leeg bij de unload functie en dat werk wel goed...

[marcusk]

Het is toch zo dat als ik iets globaal declareer, en het programma stopt (of dll ontlaadt) dat het object dan opgeruimd wordt...?

ligt eraan of je de objecten maakt op de stack of op de heap.

bijvoorbeeld, met class Blaat:

code:

Blaat g_blaaten[12];

zo worden er 12 objecten van het type Blaat op de stack gemaakt, en deze worden automatisch opgeruimd.

code:

Blaat * g_blaaten;
...
g_blaaten = new Blaat[12];

zo maak je ze op de heap (met new) dus moet je ze ook weer opruimen (met delete[] g_blaaten)

[^Mo^]

't ligt gewoon op de stack. De lijst gebruikt intern echter wel pointers, en deze worden ook goed opgeruimd mits ik dit dus expliciet laat doen.. dwz, de lijst zelf leeg laat maken. Maar de lijst wordt niet vanzelf opgeruimd (wil ik wel) als het programma stopt... 'k heb alle destructors, en ik maak in principe niks aan op de heap (behalve dus in de lijst wat het ook weer opruimt)

edit:
Als ik het trouwens lokaal doe, dus lijst vullen, bewerkingen uitvoeren, etc. dan wordt de lokale lijst wel goed opgeruimd, maar als ik dus vervolgens hetzelfde doe met de globale lijst (zelfde lijst alleen globaal dus), dan ruimt ie 'm niet op als het programma stopt...

[Orphix]

Hoe meet je of er geheugen lekt?
Sommige profilers/debuggers schijnen namelijk soms die laatste opruiming niet mee te nemen.

[^Mo^]

zit in VC++... dan staat er iets als

code:

Detected memory leaks!
Dumping objects ->
{3760} normal block at 0x014E6488, 12 bytes long.
 Data: <Juman Sucks > 4A 75 6D 61 6E 20 53 75 63 6B 73 00 
{3759} normal block at 0x014E73B0, 21 bytes long.
 Data: <Llama Whippin' I> 4C 6C 61 6D 61 20 57 68 69 70 70 69 6E 27 20 49 
{3758} normal block at 0x014E6BA8, 9 bytes long.
 Data: <Nullsoft > 4E 75 6C 6C 73 6F 66 74 00 
Object dump complete.
The thread 0x520 has exit

anders namelijk niet...

[Verwijderd]

Bij de standaard C++ array en de MFC arrays is het in principe altijd zo dat als je zelf objecten met new aanmaakt en ze in een array stopt (die op de stack is gemaakt) bij het afsluiten die array op de stack wel netjes zijn eigen zooi opruimt maar verder van de pointers in de array afblijft. Als jij die dus met new op de heap hebt aangemaakt dan moet je zelf alle pointers dus nog deleten! Doe je dit niet dan zit je inderdaad met een memoryleak.
(en in dat geval doe je het nu dus goed: tijdens het unloaden van de dll moet je dan je eigen zooi opruimen)

Mocht dit nog steeds niet al te veel helpen post dan effe de code waarin je die objecten aanmaakt+delete+in de array stopt