general Qu about debugging in CB with mingw

[prokaion]

Hi!

this is partly a question about programming and debugging in general...

1. i suppose when i check/uncheck the "produce debugging symbols" -box in Compiler-Flags is the same like using the debug/release-build in e.g. VC6??

2. in source-code i´ve read, i often find lines like:
#ifdef _DEBUG
...
#endif

is this Visual C++ -specific?
how could one use similar tricks when programming with mingw (and codeblocks using mingw)??

3. what options in Build-options->Compiler-Flags should one use, when developing a new (complex) program??

[thomas]

1. Yes and no. The option "produce debugging symbols" does just what its title says, nothing else. Generally, this should not matter much, but gcc has a few peculiarities, for example, it is very well possible to generate debugging symbols and turn on optimisations at the same time. Yes, this actually works, gdb explicitely supports debugging optimised code.  :shock:
Another difference is that not enabling "produce debugging symbols" does not dead-strip asserts as you might possibly expect.
By definition, nothing inside an assert() statement is evaluated in a release build. This is implemented using the NDEBUG constant.

2. You can use whatever you want, the best thing would be to use #ifndef NDEBUG, however, since this is "standard".

3. First, enable "show all compiler warnings" (-Wall) and "produce debugging symbols". Whenever the compiler complains about something (due to -Wall), change your code so it passes without a warning. Many things will seem very pedantic to you, but trust me, it is for your own good. If the compiler tells you "hey this does not look right", then it is not right
When your program is mature enough for a release, enable optimsations (simply -O2 or -O3 will do), and remove "produce debugging symbols" or simply enable "strip executable" (that will remove the symbols either way).

[Michael]

1. i suppose when i check/uncheck the "produce debugging symbols" -box in Compiler-Flags is the same like using the debug/release-build in e.g. VC6??

I would not try to compare MinGW with VC6. It can just lead to confusion. If the box "produce debugging symbols" is checked, then debugging symbols are added and you will be able to debug your application (e.g., with gdb).

2. in source-code i´ve read, i often find lines like:
#ifdef _DEBUG
...
#endif

is this Visual C++ -specific?
how could one use similar tricks when programming with mingw (and codeblocks using mingw)??

No. It is a preprocessor instruction. If defined, the code between #ifdef and #endif is executed. With C::B and In MinGW you can use it too. Just add it into Project-->build options-->Compiler-->#defines.

3. what options in Build-options->Compiler-Flags should one use, when developing a new (complex) program??

Difficult to answer. Depend on your project and on the software development processes you use. You can define for example a target for debug with the "produce debugging symbols".

[EDIT]: Thomas was faster and more accurate.

Best wishes,
Michael

[prokaion]

thanks!

but where is the constant NDEBUG defined?  do i have to define it?
if so, how to get the code inside the

#ifdef NDEBUG
...
#endif

statements out of the release version?

i suppose just commenting out the #define NDEBUG line??

(sorry, i have no experience in debugging techniques...)

[thomas]

where is the constant NDEBUG defined?  do i have to define it?

It is not defined, that's the trick.

You write #ifndef NDEBUG which will normally always be true, since NDEBUG is not defined, so the code between #ifndef and #endif is built into your program.

However, if you want to compile a "release build", you define NDEBUG by writing NDEBUG into the "defines" tab in compiler options (or, alternatively, by putting -DNDEBUG in "other options"). That way, the #ifndef will evaluate to false, and the code between the preprocessor directives will be eleminated as if it were not there at all. Consequently, this means that your code still has to be functional without what's in there, only redundant sanity-checks should be #ifndefed

Look into assert.h for "the" standard example. assert() is implemented exactly like that.

You can of course use any other variable constant, too, to the same effect. However, since there is a standard, why not use that

[prokaion]

Thanks!! that was pretty clear!   

[yop]

...gdb explicitely supports debugging optimised code.  :shock:

Have you ever tried that? It's really funny you step in the code and you just jump up and down as the optimisation has rearranged your code.

[thomas]

Have you ever tried that? It's really funny you step in the code and you just jump up and down as the optimisation has rearranged your code.

It is extremely cool that it works at all.

The explanation for this feature is cool, too:

Unlike most other C compilers, GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.

Did I ever mention that gcc is the coolest compiler on this planet? :lol: