问题
I am writing a C++ MFC-based application. Occasionally I will add #if defined(_DEBUG) statements in order to help me during the development process. My manager has demanded that I remove all such statements as he doesn't want two versions of the code. My feeling is that without the ability to use #if defined(_DEBUG), bugs are more likely to creep in undetected during the development process.
Does anyone else have any thoughts on this?
回答1:
Well, the runtime library, and the MFC has two versions, debug and release, so there will always be two versions of the code.
The usage of #ifdef(_DEBUG) and assert() will help you in the debugging process.
BUT...
It is not recommended to add class/struct members in an #ifdef clause, because the binary interface of the object will be different, and if you serialize or sending such a struct from debug and release versions they will be different.
E.G:
#include <assert.h>
class MyClass
{
void SetA(int a)
{
assert(a<10000); // this is recommended
}
#ifdef _DEBUG
int m_debugCounter; // This is not recommended
#endif
};
in the example, sizeof(MyClass) is different from debug and release versions.
回答2:
There are pros and cons for having debug code compiled out of production code.
Some of the pros:
- The production executables will be smaller
- Resources are not wasted preparing logging messages, statistics, etc which are never used
- You may be able to remove dependencies on external libraries, if they are only used by the debugging code
Some of the cons:
- You end up with two different executables
- It makes troubleshooting in the field more difficult because some of the debugging logs are not available in the production version
- There is a risk that the behavior of the two versions is not the same. For examples, bugs might appear in the production version which did not appear during testing because the testing was done in the debug version
- There is a risk of incompatibilities between the versions, such as files having slightly different formats (as indicated in eranb's answer).
In particular, if using code compiled out (even assert() calls) be very careful that the debug code has no side effects. Otherwise you will create bugs which disappear when debugging is turned on.
You can achieve at least some of pros by using a decent logging framework. For example, I have had some success using rLog - one of the things I like about it is that it is optimized to minimize overhead of dormant logging statements. Other more up to date logging frameworks provide similar functionality.
Having said that, every C++ environment I have worked with has at least some level of compile in/out of debug code. For example, assert() is compiled in/out depending on the NDEBUG macro. The ASSERT() / _DEBUG seems to be an MSVC specific variation on that theme (although as far as I know MSVC also supports the more standard assert() / NDEBUG).
回答3:
If the manager wants this he doesn't understand to target code quality... If #if should be removed you can also remove ASSERTs of any Kind. Because they just hide the #if _DEBUG. And Keep in mind that the MFC and CRT itself is full of this (real) useful #if _DEBUG code!
Without such special _DEBUG blocks I wouldn't be able to target misuse of classes, or to trap internal problems.
来源：https://stackoverflow.com/questions/20392059/use-of-if-defined-debug