Opinions - Debug/Release and something in between
-
For years now we have all been working with two software configs Debug and Release (cross product with other things like Unicode, or various languges etc.) I have been thinking about adding an additional type of config to my projects, and wanted your opinions. Debug, of course, is overloaded with extra debugging checks, ASSERTS, ASSERT_VALID and so forth. Consequently, it is loaded down with extra stuff that makes it run slow. (Also the optimizer is generally off to make single stepping code easier.) Release turns off all that stuff to maximize the speed of the program (which, BTW, usually means mimizing the size of the program rather than the number of instructions on modern CPUs, but that is a different issue.) I have been considering an intermediate type of configuration, call it Rebug a combination of Release and Debug. This tool keeps all the ASSERTS and other debugging tools, but redefines them to log as errors, and dump minidumps as opposed to breakpoints. Similar with unhandled exceptions etc. Rebug is also stripped of symbols (though I keep a pdb.) What is the purpose of Rebug? Well it is released as part of the install, and installed right next to the release version. If a bug happens in the field, the user can switch to the Rebug version (presumably through a menu command in the Release version), recreate the bug, and generate all sorts of tracking information for the debugger back at home base. In particular it catches problems early, by detecting failed assertions, uncaught exceptions, and so forth. Rebug would also include various options like range checking, stack frame checking, dog tags and so forth. It would allow the generation of a good debug run in the field for debugging without sending out the debug version, and having a breakpoint fire in the middle of a real user session. Why not just use the standard XP mechanism for handling crashes? Because the Rebug version can potentially catch the problem early enough that it is readily apparent what is happening, rather than looking at a static picture where the data set is already screwed up. I wonder what y'all think of this idea?
-
For years now we have all been working with two software configs Debug and Release (cross product with other things like Unicode, or various languges etc.) I have been thinking about adding an additional type of config to my projects, and wanted your opinions. Debug, of course, is overloaded with extra debugging checks, ASSERTS, ASSERT_VALID and so forth. Consequently, it is loaded down with extra stuff that makes it run slow. (Also the optimizer is generally off to make single stepping code easier.) Release turns off all that stuff to maximize the speed of the program (which, BTW, usually means mimizing the size of the program rather than the number of instructions on modern CPUs, but that is a different issue.) I have been considering an intermediate type of configuration, call it Rebug a combination of Release and Debug. This tool keeps all the ASSERTS and other debugging tools, but redefines them to log as errors, and dump minidumps as opposed to breakpoints. Similar with unhandled exceptions etc. Rebug is also stripped of symbols (though I keep a pdb.) What is the purpose of Rebug? Well it is released as part of the install, and installed right next to the release version. If a bug happens in the field, the user can switch to the Rebug version (presumably through a menu command in the Release version), recreate the bug, and generate all sorts of tracking information for the debugger back at home base. In particular it catches problems early, by detecting failed assertions, uncaught exceptions, and so forth. Rebug would also include various options like range checking, stack frame checking, dog tags and so forth. It would allow the generation of a good debug run in the field for debugging without sending out the debug version, and having a breakpoint fire in the middle of a real user session. Why not just use the standard XP mechanism for handling crashes? Because the Rebug version can potentially catch the problem early enough that it is readily apparent what is happening, rather than looking at a static picture where the data set is already screwed up. I wonder what y'all think of this idea?
We have been using this sort of setup for a few years now, and it is very usefull indeed. In fact, we usually have more than just debug,release and the one you call "rebug". We also have Debug Optimised, ( "Derel" ? :) ), which is the full debug-build with optimisation turned on. When you have something which only crashes in release, it can be good to go backwards towards the normal debug build through these two extra targets. The only problem with the scheme is that multiple configurations like these are poorly supported by VC...well, at least VC 6. It's a hassle to maintain and there are bugs which will mess up your configurations when you alter options in the menus. The configuration manager in VC 7 seems better. -=jarl=-