Re: replicating default constructor's "non-initializing state"
In article <d1deb2e6-e0bd-4b95-b17a-08c7399506b8@s37g2000prg.googlegroups.com>,
Jason Doucette <jdoucette@gmail.com> wrote:
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.)
Beyond reason? All memory is either read first or written to
first. If you want to prove write happened first, you've got
to do just that. Consider this (admidittedly pathological) case:
void foo(int& v)
{
if(rand() & 0x01)
v = 0;
}
int main(int argc, char** argv)
{
srand(time(NULL));
int v;
foo(v);
printf("v = %d", v);
return 0;
}
Sometimes, things are initialized, sometimes not. I just compiled
this with DevStudio 2005SP1, debug win32 console app. Guess whether
warning level 4 catches this - Nope. I went to C/C++ properties,
selected basic runtime checks, and set to both (stack frames +
uninitialized varbs). Then I ran it. Sometimes, I get v=0, sometimes
v=-858993460 (0xCCCCCCCC). Did I get a single notice that it was used
uninitialized? Nope. Are you so sure these DevStudio "checks" are
worth the electrons they printed on?
(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.
If it did cover this, I wouldn't have mentioned it. MSVC++ doesn't
trap uninitialized variables in allocated memory, only locals on the
stack. Boundschecker/Valgrind will do this. They'll catch the error in
my pathological testcase above. (Well, assuming that you win the
rand() lottery.) Are you programming defensively enough yet? Don't
have any rose-colored glasses about what MSVC++ covers, until you've
proven it works.
(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?
We ran a large (200,000+ lines of code) app written at work.
Coverity found a *lot* of things that were sketchy at best, and
downright unsafe at worst. All the code had been compiling at warning
level 4 for years. (Minus a few ignorable ones like identifier
truncated to 255 chars, etc). I doubt it's cheap, though, but I wasn't
involved in that process -- just the job of fixing what it did find.
Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein