[c++]memory leak

[giuseppe500]

ciao.
E' circa un anno e mezzo che programmo in c++ e una delle cose piu' terribili sono i memory leak.
Esiste un modo per sapere quale elemento(array o oggetto)non è stato eliminato?
o qualche utile informazione in piu?
Grazie

[Xaratroom]

Non credo ci sia nulla di standard o indipendente dalla piattaforma ...
È (per quel che ne so) compito del programmatore evitare memory leak.
Esistono tuttavia diversi garbage collector (orribili a mio dire).

Esistono anche dei programmi di debug tipo valgrind
http://it.wikipedia.org/wiki/Valgrind

[pallinopinco]

Esistono tuttavia diversi garbage collector (orribili a mio dire).

Cosa ha di orribile il garbage collector di Hans Boehm rispetto all'allocazione manuale della memoria gestita da programmatori inesperti (quella sì, davvero orrenda)?

[Xaratroom]

Originariamente inviato da pallinopinco
Cosa ha di orribile il garbage collector di Hans Boehm rispetto all'allocazione manuale della memoria gestita da programmatori inesperti (quella sì, davvero orrenda)?

Già, hai pienamente ragione

[MItaly]

Mah, a me non piace molto che il garbage collector debba dedurre cosa sia un puntatore e cosa no... mi sembra (almeno in teoria) un sistema piuttosto soggetto ad errori.

[pallinopinco]

Se il garbage collector è ben progettato e ben implementato basta non "nascondergli" i puntatori (bisogna allocare la memoria seguendo le guidelines ufficiali), d'altra parte progetti complessi come Mono, GNU Objective C runtime e GCJ usano un GC senza incorrere in problemi. Sono pochi i casi in cui un GC può essere di intralcio, ad esempio nel caso di applicazioni ludiche il non determinismo dell'operazione di garbage collection rappresenta un forte limite all'adozione di un GC. Per il resto delle applicazioni IMHO dovrebbe essere imposto per legge...

Inoltre, per agevolare il compito dei programmatori, spesso vengono fornite delle interfacce per facilitare il tracciamento dei puntatori.

[shodan]

Opinione strettamente personale.

A me non piace proprio l'idea di un garbage collector in C++.
Ho dato un'occhiata al codice di quello proposto e ho notato che deve ridefinire allocatori, operator new e delete globali (togliendo il throw std::bad_alloc in caso di fallimento della new e altre cose varie.) perché l'accrocchio funzioni.
Certo, per un programmatore in erba può essere utile ma la memoria non è l'unica risorsa su un PC.

Comunque lo si guardi, il garbage collector in C++ (allo stato attuale almeno) è un papocchio senza capo ne coda e rischia di introdurre problemi risolti al 90% da un buon boost::shared_ptr (unico neo è il doversi scaricare oltre 30Mb di libreria per averlo).

Se il prossimo standard C++ introdurrà il GC spero che i produttori di compilatori lo rendano disattivabile.

[MItaly]

Personalmente invece il GC non mi dispiace per niente (prima di imparare il C++ ho lavorato in .NET e il GC mi faceva gran comodo), ma se sa seguire davvero i puntatori senza doverli cercare analizzando la memoria.
Tra parentesi ho letto sulla Wikipedia che il nuovo standard C++ dovrebbe introdurre degli "aiuti" per i garbage collector: se questo vuol dire che memorizzerà in automatico tutti i puntatori utilizzati da qualche parte associandoli con gli oggetti che li posseggono sarà finalmente possibile scrivere un buon GC per il C++ che non debba "indovinare" i puntatori, ma che vada a colpo sicuro su quelli veri, evitando così di dover analizzare tutto lo stack ad ogni collection (anche se personalmente sono convinto che, usando al posto dei puntatori qualche strana alchimia di template si possa già fare questo mestiere).

[pallinopinco]

(anche se personalmente sono convinto che, usando al posto dei puntatori qualche strana alchimia di template si possa già fare questo mestiere)

Gli Smart Pointers, magari nell'implementazione fornita con la Boost?

[shodan]

E che di fatto sono stati adottati dal C++0X.

Qui c'è una considerazione di Stroustrup sul tema. (Un cognome più facile no? )

http://www.devx.com/SpecialReports/A...38813/0/page/4

Qui invece una panoramica sul nuovo standard

http://www.devx.com/SpecialReports/Door/38865