> >Debug builds that zero out everything will hide bugs in code that
> >works properly if all variables are zero'ed out, but doesn't work
> >properly if all variables are set to random values. Unfortunately,
> >when the code is run on customer's machines, they are running in the
> >Release build which is using the random values. That's why Debug
> >should forcibly randomize all unset values to force bugs to appear,
> >and force the programmer to make sure his code is legitimate. (Note
> >that I am talking about native data types.)
>
> Should do this? Maybe-- such a thing being unavoidable would merely
> annoy those people that can write good code from day 1. Will it do it?
> Very darn unlikely. The current default behavior of *optional*
> filling to fixed values is probably going to be as good as you get out
> of the box.

True, the MSVC++ compiler already fills them with C's, so that'll
catch most issues. And the MSVC++ compiler's run time checker stops
the code dead as soon as you access it, so that catches ALL issues.
(Keep in mind I wrote the above while still under the false impression
that it just 0's them out, and the run-time checker doesn't halt on
use of uninitialized variables.)


> If you want to check that variables are initialized before use,
> there are a few options: (1) ramp warning level to 4, and the compiler
> will check most local variables for use w/o initialization.

That's the first thing I do for any project! (It appears MSVC++
IDE remembers this for subsequent projects, or perhaps this is its
default, which is great!)

> (2) For
> classes, add in a constructor in debug builds (only) that checks for
> initialization.

Good tip.

However, in *my* particular case, my color struct is more of a native
data type than a class. So, it's used everywhere, and such checks
would really, really slow down the Debug builds. (Imagine having a
Debug check on each initialization and use of "int". This would be
beyond reason for such a type.) I *agree* that this is a good tip for
most classes, just not native data types. For them, having the
compiler warn about use before initialization is more than fine, which
is exactly the thing I'm griping about losing when C++ forces me to
create my own default constructor.

> (3) Pay $$$ for a program like Boundschecker that'll
> make a super-special debug build that does runtime checks for
> uninitialized variables. (If building for linux, Valgrind is supposed
> to be able to do this at a much reduced price.)

MSVC++ has this covered, so I'm all set.

> (4) Run your program
> thru static code checkers, like Coverity, that'll do an amazing job of
> finding codepaths under which local variables aren't initialized. (Far
> better than warning level 4).

I've heard of these. Amazing programs... Have you had experience
with them?

> Short summary of things: there's a few ways you can try and find
> problems like the above for free, and several ways you can spend $$$
> and find them faster. As lots of people have mentioned, your
> insistence on shaving a few ms in release builds is probably hurting
> you. You can very easily write some code that does a bunch of checks
> in debug, and goes away in release builds.

There's a misunderstanding that I'm producing bad code to shave off ms
in Release builds. I know of, and employ, many Debug build checks...
assert() calls being the most numerous, but I even have some of my own
in-depth methods for catching even more things. Trust me, I am not
trying to save ms of time. I am trying to produce robust code. The
fact that I lose the default constructor, and thus lose the compiler's
warning of using a variable before being initialized (both at compile
time and at run time), is not a good thing. This allows bugs to creep
in. This is what my post is all about.

Luckily, in the new C++ standard, my desire of keeping the default
constructor is something I can do. I hope the MSVC++ compiler
implements this feature soon.

Thanks for your time, Nathan.

Jason