Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Miles Bader Newsgroups: comp.lang.c++ Subject: Re: Memory Leak Detection Date: Wed, 14 Sep 2011 15:24:27 +0900 Organization: NEC Electronics Lines: 20 Message-ID: References: <7be371ee-c86c-4686-adbb-d0f3f716cde9@j1g2000yqn.googlegroups.com> <1073300f-64a0-4665-9e6e-a5000808b407@z7g2000vbp.googlegroups.com> <4e70444c$0$4388$7b1e8fa0@news.nbl.fi> Mime-Version: 1.0 Content-Type: text/plain X-Trace: individual.net LppiIXc9smCqwtMOglFFSgIVWasxyHn83X9afrhYCkreHkO9zc Cancel-Lock: sha1:gPyDzJi3dQDZe5xkKKs3kXHipuE= sha1:GSuCl/7b9DfctycXnQDhmFKO7WM= System-Type: x86_64-unknown-linux-gnu Blat: Foop Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:10095 Juha Nieminen writes: > Miles Bader wrote: >> [Running valgrind on a program for the first time can be a rude shock >> though, revealing tons of little bugs that you never noticed before!] > > Actually if you have followed the basic rules of RAII and all the > rules that naturally follow from it (such as the so-called rule of > three, never use a raw 'new', use the STL whenever it's suitable, > and so on), such bugs become rarer and rarer. Sure, I do follow those guidelines -- and indeed they help greatly (I've found my programs in "proper" C++ to be much less buggy than my programs in C, or in "non-proper" C++) -- but nonetheless, in any non-trivial program, bugs are present, and valgrind is a _very_ useful tool for finding many of them. -Miles -- If you can't beat them, arrange to have them beaten. [George Carlin]