Sono abbastanza nuovo di C++ ma ho alcune conoscenze di base. Nei miei precedenti progetti C (universitari), ho usato Valgrind per verificare la presenza di memleaks.Valgrind utilizzato nello sviluppo C++?
Ora, con C++, Valgrind è uno strumento valido? C++ subisce gli stessi problemi riguardanti memleaks come C? O ci sono anche strumenti migliori da usare in combinazione con C++?
Non utilizzo mai new e delete (o altre forme di gestione manuale della memoria) e molto raramente utilizzo puntatori. E I ancora devono lottare con le perdite di memoria non valide. Valgrind è uno strumento indispensabile per me. Ancora più importante di gdb.
Come Viktor ha sottolineato in un commento, producendo perdite di memoria senza gestione manuale della memoria sarebbe piuttosto strano (attualizzando i riferimenti circolari e altri casi particolari).
Valgrind può essere utilizzato per controllare memleaks in C++ anche
valgrind ha tante opzioni che vi darà informazioni e si può esplorare anche callgrind.
--Cheers
perdite di memoria sono una preoccupazione per me come sviluppatore C++. Presumo che siano una preoccupazione anche per altri sviluppatori, anche se non posso parlare per tutti. Valgrind è uno strumento fantastico in questo spazio e uno di cui non potrei davvero vivere senza.
Valgrind è lo strumento migliore disponibile per gestire gli errori di memoria (ma controllare gli altri moduli accanto a memcheck).
La programmazione in stile C è un valido (e ampiamente utilizzato) approccio di programmazione in C++, quindi sì, i problemi di memoria sono ancora un problema.
Ho usato solo memcheck. Quali altri moduli puoi raccomandare? – helpermethod
Mentre C++ ha una gestione della memoria molto migliore di C, è ancora possibile fare confusione. I puntatori intelligenti sono fantastici, ma è possibile sbagliare con loro. Ecco a cosa serve valgrind.
sì, lo è.
utilizzo l'allocazione dinamica per impostazione predefinita nei test di unità (con puntatori automatici o un equivalente idiomatico) per controllare esplicitamente ulteriori errori di memoria che valgrind potrebbe rilevare. valgrind, guardmalloc, perdite, ecc. possono catturare molti errori prima che entrino nel codice di produzione.
ricordatevi di dire runtime GCC non usare il proprio pool di memoria privata altrimenti si confondono valgrind
GLIBCPP_FORCE_NEW = 1
Apparentemente è 'GLIBCXX_FORCE_NEW' da gcc 3.4 in poi. potresti voler collegare a [FAQ di Valgrind] (http://valgrind.org/docs/manual/faq.html#faq.reports) a riguardo. – Hasturkun
Allora ti suggerisco di gestire più librerie. –
@Viktor: devo ammettere che questo * è * in gran parte un difetto della biblioteca. Ma anche le moderne implementazioni STL accettano felicemente un accesso fuori intervallo su 'operator []' senza pronunciare nemmeno un avvertimento, anche in debug built (GCC ...). –
Ma questa non è una perdita di memoria? Non voglio essere presuntuoso, ma se non scrivi mai "= nuovo" nel tuo codice (nota il "="), non ottieni perdite di memoria (sì, shared_ptrs può rimandare l'un l'altro, ma ciò accade molto raramente) –