PHWinfo - Afficher un message - replicating default constructor's "non-initializing state"

08/04/2008, 21h52

In article <0f38d01d-718f-495e-b5f0-da59949868b1@w5g2000prd.googlegroups.com>,
Jason Doucette <jdoucette@gmail.com> wrote:
>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.

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. (2) For
classes, add in a constructor in debug builds (only) that checks for
initialization. (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.) (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).

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.

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

08/04/2008, 21h52	#14
Nathan Mates Messages: n/a Hébergeur:	Re: replicating default constructor's "non-initializing state" In article <0f38d01d-718f-495e-b5f0-da59949868b1@w5g2000prd.googlegroups.com>, Jason Doucette <jdoucette@gmail.com> wrote: >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. 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. (2) For classes, add in a constructor in debug builds (only) that checks for initialization. (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.) (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). 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. 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