>> I wonder if valgrind would be any help... (But then of course, I'd have
>> to figure out how to build the application by hand!)
>
> valgrind exists precisely for this kind of thing. Last time I checked,
> however, it hadn't been ported to Windows, but that was a long time ago,
> so things might have changed.

Well, the application does get built for Windows and Linux. (And there 
are some fairly drastic code differences between the two.) It would 
certainly be useful to test the Linux version - and to get something 
more than just a page of hex codes to tell me what the **** is going on. 
Then again, it does mean I have to master building the thing on Linux. 
(Not as simple as clicking "rebuild solution".)

> There are other, commercial products that do the same task. However,
> given that you are working for a company, it shouldn't be such a big
> deal.

Working for a company with very little money. ;-)

> But then, I seldom need to use any such memory debuggers. 99.99% of such
> bugs can be avoided by writing the C++ code properly. I don't even remember
> when was the last time I had a memory leak in any C++ program (and I write
> C++ constantly as my payjob, and have been doing so for quite a long time.)


That's probably the problem. We write C# all day. C++ has drastically 
different semantics, which can trip you up in all sorts of ways.

Look at the post I wrote. Two bugs were due to a conspicuous use of 
"new" for which no corresponding "delete" exists. That's pretty easy to 
recognise, even if fixing it isn't necessarily easy. But the other two 
leaks were due to more unusual causes. In one case, we allocate objects 
and explicitly release them again; the only reason it leaked is because 
(unknown to any of us) you have to explicitly ask for a virtual 
destructor. The compiler doesn't figure that out for you. And the final 
leak was to do with somebody not reading the fine print on an external 
library.

I suppose if you write this kind of code all day, every day, you would 
*know* that destructors need to be virtual and so forth...

Post a reply to this message