[c++]memory leak

[MItaly]

Originariamente inviato da pallinopinco
Gli Smart Pointers, magari nell'implementazione fornita con la Boost?

Li conosco "di vista" ( ), ma da quanto ne so la cosa che più si avvicina ad una garbage collection sono i puntatori con reference counting, che non sono adatti però quando ci sono dei riferimenti circolari; so che il problema si può risolvere con i weak pointers, ma la faccenda si complica ulteriormente.
L'alchimia di template (e magari anche di macro) a cui pensavo io era un tipo di smart pointers che al momento della creazione memorizzano un puntatore all'oggetto a cui appartengono e a quello a cui puntano in una specie di repository globale a cui il GC può attingere quando pulisce l'heap, in modo che esso possa andare a colpo sicuro.

[menphisx]

Per me tutto si risolve con uno SmartPointer, che è pure facile da scrivere.
Trovo che un GC in C++, non ci stia bene. Insomma se vuoi il GC, non programmare in C++.
Per me la non presenza del GC, è un vantaggio, che mi permette di decidere cosa farne della memoria. E soprattutto velocizza i miei programmi.

IMHO ovviamente.

[XWolverineX]

Anche io sono sostanzialmente contrario al garbage collector.
Di linguaggi ad altissimo livello oramai ne abbiamo (Java, Python, tutta la famiglia .NET)

Lasciamo il C++ a quella bassezza nell'altezza di livello (mmm...)

[MItaly]

Tra parentesi, qualcuno ha già avuto la mia idea (che in effetti non era così originale).
http://www.codeproject.com/KB/cpp/garbage_collect.aspx

[giuseppe500]

scusate , ma ho trovato questo:

http://www.codeguru.com/forum/showthread.php?t=312742


di cui non ho capito tutto , ma forse è quello che cerco.
L'articolo parla ad un certo punto di come far restituire a vc ++ il file e la riga del leak.
Non ho capito pero' come precisamente.
Il problema è che io uso correggere i memory leak alla chiusura dell applicazione e l'articolo parla ad es di funzioni come _CrtDumpMemoryLeaks();Inoltre sto debuggando una dll.
Grazie.

[denis76]

Scusate se mi intrometto, conoscete un software gratuito per trovare i memory leak in un programma Win32 scritto con Codeblocks - Mingw?

[MacApp]

Uno dei grossi vantaggi del C++ è proprio la possibilità di gestire le risorse assieme alla gestione della memoria, con smart pointer opportuni.

Il GC è in un certo senso un po' uno specchietto per le allodole, il problema della gestione della memoria, quasi scompare, ma quello della gestione delle risorse rimane. Quello che a prima vista sembra un vantaggio in realtà diventa uno svantaggio perché con il GC si è costretti a gestire memoria e risorse in modi differenti.

Invece in C++ potendo gestire le risorse assieme alla gestione memoria, la metodologia diventa unica.
Il problema piuttosto è che molti programmatori non gestiscono le risorse assieme alla memoria o perché non sanno farlo (ed ok impareranno), o perché pensano che sia uno "sforzo" inutile farlo (e questo purtroppo è grave).

Tanto per fare un esempio, in Java per gestire le risorse si è costretti a far largo uso di illeggibili blocchi try catch, in C++ (per i programmi scritti bene) invece assolutamente no: le eccezioni possono essere catturate generalmente solo nelle routine di alto livello (ad esempio nel main, o nelle varie OnEvent).

@giuseppe500
Tipicamente un classico errore per principianti che genera quasi sicuramente memory leak, consiste nel non dichiarare virtual i distruttori, o derivare da classi che non hanno distruttore virtual.

[MItaly]

Originariamente inviato da MacApp
Il GC è in un certo senso un po' uno specchietto per le allodole, il problema della gestione della memoria, quasi scompare, ma quello della gestione delle risorse rimane. Quello che a prima vista sembra un vantaggio in realtà diventa uno svantaggio perché con il GC si è costretti a gestire memoria e risorse in modi differenti.

In effetti è vero, non è un caso che anche in .NET esiste l'interfaccia IDisposable per fornire un metodo manuale per liberare le risorse.

@giuseppe500
Tipicamente un classico errore per principianti che genera quasi sicuramente memory leak, consiste nel non dichiarare virtual i distruttori, o derivare da classi che non hanno distruttore virtual.

Ed è per questo che consiglio in Visual C++ (che mi pare che anche lui utilizzi) di attivare il warning C4265, che per qualche strano motivo è disabilitato di default (nota: per vederlo devi comunque impostare il livello di warning almeno a 3, anche se personalmente ti consiglio di impostarlo a 4). Tra parentesi, ti consiglio anche di abilitare il C4640 se devi scrivere applicazioni multithread.
Inserisci quindi in stdafx.h:

#pragma warning(default : 4265) //The class has virtual functions but the destructor isn't virtual
#pragma warning(default : 4640) //Construction of static local object is not thread-safe

.

[giuseppe500]

grazie gente
Mi rimane il dubbio sul link che ho postato , è possibile visualizzare la riga e il file del leak?
Io non ci sono riuscito.
ciao.

[shodan]

Io ci sono riuscito così (ma non garantisco nulla) :

// tutti gli altri header vanno sopra o si rischiano problemi di compilazione.

#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#endif

#include <crtdbg.h>

#ifdef _DEBUG
   #define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
   #define DEBUG_CLIENTBLOCK
#endif

#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif

using namespace std;

int main(int argc, char* argv[]) {
 
//	{
		auto_ptr<int> k(new int(0));
//	}
	_CrtDumpMemoryLeaks();
}

Però la funzione rileva se la memoria non è stata liberata nel momento in cui è invocata, non in generale. In questo esempio, l'auto_ptr rilascia la memoria quando il main termina quindi non c'è un memory leak anche se viene segnalato da _CrtDumpMemoryLeaks e lo puoi verificare decommentando le due graffe che forzano l'uscita dallo scope dell'auto_ptr.

Insomma attento ai falsi allarmi e non dare per oro colato le informazioni che fornisce.