Warnings

[RonHiler]

So I just this week upgraded my compiler from Builder 6 to Builder 2007, which was good, the old compiler was a few years old. The new one has lots of neat stuff to use, and I'm looking forward to it.

As a matter of course, I always turn on all compiler warnings and treat warnings as if they were errors that halted compilation. If I get a warning that I determine is something I want to be there on purpose, I'll turn off the warning for that section of code via a pragma directive, and turn it back on again afterword. A successful build for me always has 0 errors, 0 warnings. Anything else requires debugging.

Well, for a full build of MD, Builder 6 had no warnings (obviously, because I always fixed them as I got them). In Builder 2007, I now have 468 warnings Clearly they changed something in the warning system. So I've got a bit of work ahead of me to clean those all up. About 90% of them are conversion warnings. Most likely I won't do them all at once, but a rather bit at a time as I run across them.

On a somewhat more serious note, the program no longer will exit cleanly, but instead crashes when you shut it down. That's a bug I'll have to fix before the next release.

[Pix]

So I just this week upgraded my compiler from Builder 6 to Builder 2007, which was good, the old compiler was a few years old. The new one has lots of neat stuff to use, and I'm looking forward to it.

As a matter of course, I always turn on all compiler warnings and treat warnings as if they were errors that halted compilation. If I get a warning that I determine is something I want to be there on purpose, I'll turn off the warning for that section of code via a pragma directive, and turn it back on again afterword. A successful build for me always has 0 errors, 0 warnings. Anything else requires debugging.

Well, for a full build of MD, Builder 6 had no warnings (obviously, because I always fixed them as I got them). In Builder 2007, I now have 468 warnings Clearly they changed something in the warning system. So I've got a bit of work ahead of me to clean those all up. About 90% of them are conversion warnings. Most likely I won't do them all at once, but a rather bit at a time as I run across them.

On a somewhat more serious note, the program no longer will exit cleanly, but instead crashes when you shut it down. That's a bug I'll have to fix before the next release.

Sweet, I prefer to use /W4 /WX (basically, the same thing), too. Be interesting to see what you get--I bet it's 80 copies of the same 6 errors, or something. I've noticed that at some point, MS deprecated a crapload of CRT functions like fopen, strlen, and so on, and replaced them with "safer" versions, and introduced new warnings to indicate deprecated functions, so it'd be easy to take an old program that used those functions heavily and try to compile it under a recent version and have that happen.

As a hobby project, I'm trying to turn an old OS/2 program into a Windows one, and MSVC 2008 HATES a lot of what it did, including stuff like using base members in the initializer list of a derived class constructior.

[RonHiler]

Sweet, I prefer to use /W4 /WX (basically, the same thing), too. Be interesting to see what you get--I bet it's 80 copies of the same 6 errors, or something. I've noticed that at some point, MS deprecated a crapload of CRT functions like fopen, strlen, and so on, and replaced them with "safer" versions, and introduced new warnings to indicate deprecated functions, so it'd be easy to take an old program that used those functions heavily and try to compile it under a recent version and have that happen.

Aye, if you include a particular library (and I think it's <strsafe>) it undefines all those functions, including what used to be one of my favorites, sprintf. I have it included in the MDestiny code, so every time I pull older code over, I get all those warnings about those sprintf's, and I have to switch them all out to STL strings or whatever. Which is good in a way, because I would replace them anyway, and that way the debugger tells me exactly where they are, heh.

[RonHiler]

Well, after quite a bit of work, I got rid of all the warnings (and yeah, there was one "bug" per warning, so I had to fix nearly 500 of them). I wasn't really going to do all of them at once, but I had to do some pretty significant retoolling of parts of the program anyway in order to get rid of that destructor crash bug, so I figured as long as I was going through the program module by module, I might as well take care of the warnings, while I was there.

I tell you guys, I thought I was pretty good about watching memory overruns and the like, but wow, this new compiler is super strict about that sort of thing. It has a debugger function called Code Guard that watches specifically for that sort of thing. It's actually REALLY nice to have, and all by itself makes the price I paid for the compiler upgrade worth it. So far all the memory bugs that I've fixed have been harmless (which is not too surprising given that the program ran fine), but nevertheless, it's good to get them fixed so I'm not trying to access buffers past the end of where I created them.

CodeGuard IS picking up on a memory bug in the movie module, which I haven't figured out yet. I've always known there is something buggy going on in that section of the program, so maybe this will fix that (or at least make it better).

Anyway, when I turn off CodeGuard, the program runs fine now, without any crash bugs or other oddities. So the bottom line is we're getting back to where I was before the compiler upgrade, and progress will continue just as soon as I fix the errors CG is complaining of.