I'm coding in c++ because I want my program to run fast (the faster the better).
But I am disapointed at the fact that it checks whether a variables is initialized or not...
I don't want it to lose time doing it, even if it is just a nanosecond.
I use VS, and I thought that maybe if I run my program in the not-debug mode it would avoid the check. But it does the check anyway, and shows me a window with this message:
Run-Time Check Failure #3 - The variable 'carryingResourceAux' is being used without being initialized.
This line that seems to be generating the error is:
carryingResource = carryingResourceAux;
Can I avoid this check to make my program run slightly faster??
This check is enabled by the /RTCu compiler option. In the IDE, under project properties -> C/C++ compiler -> Basic Runtime Checks, change the option to not include these checks. Note that they are only compatible with no optimization (debug builds).
You should optimize your release build, and leave this check in for debug builds.
Related
I use std::map in my code, but in debug builds code that uses it runs unacceptably slower than in release. This answer says that this is because
In the Microsoft Visual Studio, there's a global lock when accessing
the Standard C++ Library to protect from multi threading issue in
Debug builds.
But it doesn't elaborate on a way to disable that global mutex lock. Is there any way to do it?
If your problem is generally that your debug build is slow using STL, I would try turning off iterator debugging. As far as I know, that's one of the big slow downs between release and debug builds. I believe the relevant #define is:
#define _HAS_ITERATOR_DEBUGGING 0
As far as I know, there isn't because some of the debug checking inside the runtime library is probably (and most likely can't be made) thread safe and thus in order to give you the additional checks, you have to have the global lock.
From experience I know the debug runtime is considerably slower but in a lot of cases, the additional runtime checks are valuable. I would also point a profiler at the code before blaming the runtime - your debug code is running unoptimized unless you tweaked the flags and as a result any performance problem in the code with be magnified because the compiler did what you told it to do :).
That said, one option that you might be able to use to work around this if you are willing to forego the additional runtime checks would be to try and build your debug version against the release runtime. I haven't tried that in quite a while but the last time I tried this did work and it might make an unacceptably slow piece of code more bearable.
I'm writing a program in C++/Qt which contains a graph file parser. I use g++ to compile the project.
While developing, I am constantly comparing the performance of my low level parser layer between different compiler flags regarding optimization and debug information, plus Qt's debug flag (turning on/off qDebug() and Q_ASSERT()).
Now I'm facing a problem where the only correctly functioning build is the one without any optimization. All other versions, even with -O1, seem to work in another way. They crash due to unsatisfied assertions, which are satisfied when compiled without a -O... flag. The code doesn't produce any compiler warning, even with -Wall.
I am very sure that there is a bug in my program, which seems to be only harmful with optimization being enabled. The problem is: I can't find it even when debugging the program. The parser seems to read wrong data from the file. When I run some simple test cases, they run perfectly. When I run a bigger test case (a route calculation on a graph read directly from a file), there is an incorrect read in the file which I can't explain.
Where should I start tracking down the problem of this undefined behavior? Which optimization methods are possibly involved within this different behavior? (I could enable all flags one after the other, but I don't know that much compiler flags but -O... and I know that there are a lot of them, so this would need a very long time.) As soon as I know which type the bug is of, I am sure I find it sooner or later.
You can help me a lot if you can tell me which compiler optimization methods are possible candidates for such problems.
There are a few classes of bugs that commonly arise in optimized builds, that often don't arise in debug builds.
Un-initialized variables. The compiler can catch some but not all. Look at all your constructors, look at global variables. etc. Particularly look for uninitialized pointers. In a debug build memory is reset to zero, but in a release build it isn't.
Use of temporaries that have gone out of scope. For example when you return a reference to a local temporary in a function. These often work in debug builds because the stack is padded out more. The temporaries tend to survive on the stack a little longer.
array overruns writing of temporaries. For example if you create an array as a temporary in a function and then write one element beyond the end. Again, the stack will have extra space in debug ( for debugging information ) and your overrun won't hit program data.
There are optimizations you can disable from the optimized build to help make debugging the optimized version easier.
-g -O1 -fno-inline -fno-loop-optimize -fno-if-conversion -fno-if-conversion2 \
-fno-delayed-branch
This should make stepping through your code in the debugger a little easier to follow.
Another suggestion is that if the assertions you have do not give you enough information about what is causing the problem, you should consider adding more assertions. If you are afraid of performance issues, or assertion clutter, you can wrap them in a macro. This allows you to distinguish the debugging assertions from the ones you originally added, so they can be disabled or removed from your code later.
1) Use valgrind on the broken version. (For that matter, try valgrind on the working version, maybe you'll get lucky.)
2) Build the system with "-O1 -g" and step through your program with gdb. At the crash, what variable has an incorrect value? Re-run your program and note when that variable is written to (or when it isn't and should have been.)
I'm working on C++ program built by other people, and saw a lot of uses of DEBUG like this
#ifdef DEBUG
cout << "Value is "<< value << endl;
#endif
I myself am still in the learning process to become an affluent C++ programmer, and I majorly use Visual Studio and breakpoints to debug. So I'm wondering, if I'm able to step through the code to debug values, is there any other reason to use these kind of macros?
Tried to google but didn't find much useful page.
Thanks.
Sometimes you don't want to step through the whole code, but just inspect the output in the terminal.
If the code is compiled with DEBUG defined, probably in a debug build, you see the output. For a release build, you don't. If you go to project settings -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions, you'll see that DEBUG is defined for the debug build, but it's not for release. (I actually have _DEBUG)
Imagine you have a huge function, and what you're interested in is at the 1000th line (it's old code, can't change it). Would you rather step through all of that messy legacy code or have helpful debug statements at key points? Would you rather the console tell you where something went wrong, or set breakpoints at each of the 237 return statements at fail locations?
While you're debugging, it is a common practice to dump some intermediate values on the screen. The visual debugger is not always helping, because you waste a lot of time manipulating with mouse.
The need for "text-mode debugging" and logging also frequently comes from the embedded systems experience, where you don't have much visual aid and all you can do is to dump a byte or two to serial port or something like that. When you get used to quickly finding critical debug points, you just insert some printing code there whose value checks the program correctness.
The "DEBUG" macro is defined by MSVC++ compiler while your project is compiled in Debug mode. When you're making the Release version, all the code which is actually useless for the end-users gets "stripped away" by the preprocessor.
Typical snippet
#ifdef DEBUG
Some code
#endif
is removed by the preprocessor if the DEBUG is not defined.
It can be handy to use console output rather than a debugger for identifying multithreading bugs. Interrupting the flow of the program via a breakpoint often stops the bug from occurring because it stops the threads stepping on each other's toes. The same is true of other timing-based bugs.
"I majorly use Visual Studio and breakpoints to debug"
Debugging your code by watching its behaviour step by step is quite hard or even impossible in some situations. Sometimes it's just easier to create this kind of "debug output" so that you see what's going on from these logs instead of trying to step through it in real time.
Checking whether DEBUG symbol is defined is to make sure that your release version doesn't make this kind of output. Note that Visual Studio defines _DEBUG for debug configuration. More specifically: "The compiler defines _DEBUG when you specify the /MTd or /MDd option. These options specify debug versions of the C run-time library."
There is also NDEBUG that disables C-style assertions when defined. For more information check _DEBUG vs NDEBUG.
It's for debugging, by wrapping the code in preprocessor commands you can turn that code on or off.
Take a look here: C++ Notes: Preprocessor
Easy, when you want to get some messages that may help you to make a "soft" debug you just define DEBUG and the sentences between #ifdef DEBUG and #endif will make effect and in your case get some useful messages.
This way, when you finished developing and you want to make a release you just undefine debug and the messages will appear no more.
You may think yes, it is a good idea, but is more code for the app but the good point is that those are macros and are evaluated at compile time, therefore, the app will be the same that if you delete all of them :)
I'd recommend not using a DEBUG macro. Instead, use the standard NDEBUG macro, which is defined when debugging code is not wanted, rather than defined when debugging code is wanted. That is, have debugging code active by default. You will find that only a small core of performance critical code needs to have debugging checks switched off to get adequate performance.
As the question explains: I would like to add some debugging code that only runs when the program is attached to the debugger. I would imagine that this flag or pre-processor variable would be different for every compiler...
In my case I am using Microsoft Visual Studio 2010 with C++.
I also use Eclipse on another computer at home running Ubuntu 10.4 and again in C++.
This question could mean 1 of 2 things:
Code that only runs based on the build configuration (e.g. Release vs. Debug)
Code that only runs when the debugger is attached
Based on build configuration
This can be solved by using the pre-processor macro relevant to your compiler (e.g. _DEBUG for the Win32 CRT).
Based on whether debugger is attached
This can be solved in several different ways.
Global boolean variable
One way I find is to define a global boolean variable which is initialised to false, like this:
bool gDebug = false;
And when I have attached to the code with my debugger, break in the code and override gDebug with true via the Watch window. Then you can add code that runs conditionally if this is set is true:
if (gDebug)
{
// Debugger is attached, so run this code
// ...
}
Registry key
Define a DWORD registry value which is initialised to 0, but you can override to 1 via the registry editor.
You then make your debug code conditional on this registry value being set to 1. This may be a better alternative as you can control this value externally without have to break in your debugger to set a global variable at the appropriate time.
If you want to have some code included or not in debug/release builds, usually the _DEBUG preprocessor macro is defined for debug builds (at least, in MSVC++ CRT that is the convention), but it doesn't detect if a debugger is attached, it just let you include different code for debug/release builds.
If what you want is a runtime check for attached debuggers, you should use the IsDebuggerPresent API, which detects if a user-mode debugger is attached.
Notice that it's not 100% reliable since, with some not-so-difficult work, the debugger can make it lie to your application. In other terms, it's not good for security/anti-cheat protection and this kind of stuff, it's more to enable additional help to the debugger (e.g., as the page itself says, output more diagnostic info with OutputDeubgString, etc.). Moreover, it won't detect kernel-mode debuggers, that can do whatever they want anyway.
Anyhow, I advice you to avoid using this function for complicated stuff, since you're introducing different code paths when the debugger is attached, and this can make debugging "strange" bugs quite difficult. All the code I indirectly used which presented such behavior (e.g. the almost undocumented Windows debug heap) always gave me bad headaches.
Set a global variable in_debugger to false in your program. Condition all your debug-only code on this variable being true. Set the variable to true when you attach your debugger.
There is an even more direct approach to this. You can manually call a function of your choice during the debugger session:
http://sourceware.org/gdb/onlinedocs/gdb/Calling.html
Regards,
Marcin
So I have just followed the advice in enabling debug symbols for Release mode and after enabling debug symbols, disabling optimization and finding that break-points do work if symbols are complied with a release mode, I find myself wondering...
Isn't the purpose of Debug mode to help you to find bugs?
Why bother with Debug mode if it let bugs slip past you?
Any advice?
In truth there is no such thing as a release mode or a debug mode. there are just different configurations with different options enabled. Release 'mode' and Debug 'mode' are just common configurations.
What you've done is to modify the release configuration to enable some options which are usually enabled in the debug configuration.
Enabling these options makes the binaries larger and slower according to which ones you enable.
The more of these options you enable, the easier it is to find bugs. I think your question should really be "Why bother with release mode?" The answer to that is that it's smaller and faster.
Debug mode doesn't "let bugs slip past you". It inserts checks to catch a large number of bugs, but the presence of these checks may also hide certain other bugs. All the error-checking code catches a lot of errors, but it also acts as padding, and may hide subtle bounds errors.
So that in itself should be plenty of reason to run both. MSVC performs a lot of additional error checking in Debug mode.
In addition, many debug tools, such as assert rely on NDEBUG not being defined, which is the case in debug builds, but not, by default, in release builds.
Optimisations will be turned off, which makes debugging easier (otherwise code can be reordered in strange ways). Also conditional code such as assert() etc. can be included.
Apart from your application being very debuggeable in release mode, the MSVC runtime libraries aren't so nice, neither are some other libraries.
The debug heap, for instance, adds no-man's land markers around allocated memory to trap buffer overruns. The standard library used by MSVC asserts for iterator validity. And much more.
Bugs due to optimisers aren't unheard of; but normally they hint at a deeper problem, for instance, not using volatile when you need to will cause optimiser bugs (optimising away comparisons and using cached results instead).
At the end of the day, including debug symbols in early releases can help you trace down bugs after deployment.
Now, to answer your questions directly:
Debug mode has other things, like assert()s which are stripped in release mode.
Even if you do all your testing in release mode, bugs will still slip by. Infact, some bugs (like the above volatile bug) are only hidden in debug mode: they still exist, they are just harder to trigger.
Including full symbols with your application includes significant information about the build machine (paths etc. are embedded).
The advice is to include "PDB Only" symbols with release builds (don't include file, line and local variable symbols) with optimisation on. And debug build has no optimisation and full symbols.
And (as noted in other answer) common sub-expression elimination and instructin reordering can make debugging interesting (move next goes to lines n, n+2, n+1...).
optimization is a nightmare for debugging. Once i had an application with this for loop
for (int i = 0; i < 10; i++)
{
//use i with something
}
i was always 0 in debugging. but outputting it to a console showed that it did increase