Memory Leak Detection with Visual Studio 2008

Brad Fish told me that Visual Studio 2008 was definitely worth the upgrade (especially on Vista), so I took the plunge. For a C++ programmer, I don't think it was as cool of a jump as 2003 to 2005 and not even close to the HUGE jump from 6 to 2003 (I skipped 2002), but it's still been a very nice upgrade.

But anyway, I have been working on making my own little SQLite3 C++ wrapper, because I just didn't like the ones that I could find out there. While doing that I also decided that it would be easiest to use a smart pointer to manage all of the pointers to SQLite stuff. I had played around with the Boost shared_ptr, but once again I just didn't like some of the syntax (mostly the custom deleter being in the constructor rather than a template parameter), so I just dusted off some old shared pointer code of my own and added a custom deleter to it.

It all seemed to be working just fine, but I just wanted to make sure that I was cleaning everything up properly and then I remembered that the current versions of Visual Studio don't dump out the memory leaks like Visual Studio 6 used to do by default. So I started some Googling and found this page. It says that it doesn't work with Express Edition, but it must be a typo or something, because it works (just not quite as described). Basically, here's what I was able to figure out from playing around with it. All you need to do is:
1) Add the header crtdbg.h
2) Call _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

You can find out more about _CrtSetDbgFlag() here, but calling it this way this will turn on the printing out of the memory leaks when your program exits (only when _DEBUG is defined).

After creating some artifical memory leaks, I noticed that it didn't dump the line that the memory was allocated on like it used to. So I did a little scavenging through the crtdbg.h header file and I found a conditional compile that would enable the printing of the allocation line. I added the two conditions to my code:
#define _CRTDBG_MAP_ALLOC
#define _CRTDBG_MAP_ALLOC_NEW
But unfortunately, this is just a mechanism to allow old code to still compile, because now it just prints the line in the crtdbg.h file. This is obviously useless (something that's I just noticed is also pointed out in the comments of the crtdbg.h file), so I guess this is the first thing I've found in the newer versions of Visual Studio that just aren't up to par with Visual Studio 6 (I know I didn't think I'd ever say/hear/read that either).

I guess that I should just be happy that I was able to get my memory leak dump again, but I'm still wondering why that's not on by default.

Integrity is a Virtue

I've finally accepted that I'm kind of obsessive/anal when it comes to programming and that's probably why I'm so fascinated by C++ instead of all of the other crazy languages out there. But I've started playing around with SQLite and it really bothered me that it didn't enforce foreign key constraints. So I did some digging and found this. It's a description of how you can use triggers to enforce foreign keys. It's actually a pretty slick idea and allows people that want/need them to turn them on without the unnecessary overhead for those that don't care (but it would still be nice if this was just added as a code thing that could be taken out with conditional compilation). But the little online tool is pretty handy and I'd definitely recommend it to anyone that's using SQLite.

static Initialization Order Fiasco

So I haven't posted on here in quite some time, but I wanted to post about something I learned this week. It's called the "static initialization order fiasco" and it's pretty crazy. First off I always remember that "static is evil" and try to avoid it, but I was helping someone else try and debug a problem and they had used a bunch of C++ fanciness (returning references to static variables inside a static member function) to "hide" the use of global variables and it was coming back to bite them. At first I thought that it must have been some memory problem that they were incorrectly using/overwriting memory, but it ended up being this. It's pretty crazy what types of messes that people can get themselves into when they're trying to be "fancy" but real don't know what they're doing.

Also, I love that "lite" FAQ by the way. It's always got GREAT information and it's usually very well written and very clear. Anytime I have a question about C++, syntax, or odd problems that's the first place I look.

Blogger Util

So I haven't had time to put all of my old code up yet, but I'll get around to it soon. My current project is that I'm learning Python, so I can make a little Blogger Util that will automatically get all of the feeds for you to import into an RSS Reader. I'll add some more info as I get it up and running.