Debug vs. Release

[Techno Learner]

Sorry for the lame question but, what's the difference between Debug
and Release versions?

 

[Ben Pfaff]

Sorry for the lame question but, what's the difference between Debug
and Release versions?

Your question is outside the domain of comp.lang.c, which discusses
only the standard C programming language, including the standard C
library. This is a remarkably narrow topic compared to what many
people expect.

For your convenience, the list below contains topics that are not
on-topic for comp.lang.c, and suggests newsgroups for you to explore
if you have questions about these topics. Please do observe proper
netiquette before posting to any of these newsgroups. In particular,
you should read the group's charter and FAQ, if any (FAQs are
available from www.faqs.org and other sources). If those fail to
answer your question then you should browse through at least two weeks
of recent articles to make sure that your question has not already
been answered.

* OS-specific questions, such as how to clear the screen,
access the network, list the files in a directory, or read
"piped" output from a subprocess. These questions should be
directed to OS-specific newsgroups, such as
comp.os.ms-windows.programmer.misc, comp.unix.programmer, or
comp.os.linux.development.apps.

* Compiler-specific questions, such as installation issues and
locations of header files. Ask about these in
compiler-specific newsgroups, such as gnu.gcc.help or
comp.os.ms-windows.programmer.misc. Questions about writing
compilers are appropriate in comp.compilers.

* Processor-specific questions, such as questions about
assembly and machine code. x86 questions are appropriate in
comp.lang.asm.x86, embedded system processor questions may
be appropriate in comp.arch.embedded.

* ABI-specific questions, such as how to interface assembly
code to C. These questions are both processor- and
OS-specific and should typically be asked in OS-specific
newsgroups.

* Algorithms, except questions about C implementations of
algorithms. "How do I implement algorithm X in C?" is not a
question about a C implementation of an algorithm, it is a
request for source code. Newsgroups comp.programming and
comp.theory may be appropriate.

* Making C interoperate with other languages. C has no
facilities for such interoperation. These questions should
be directed to system- or compiler-specific newsgroups. C++
has features for interoperating with C, so consider
comp.lang.c++ for such questions.

* The C standard, as opposed to standard C. Questions about
the C standard are best asked in comp.std.c.

* C++. Please do not post or cross-post questions about C++
to comp.lang.c. Ask C++ questions in C++ newsgroups, such
as comp.lang.c++ or comp.lang.c++.moderated.

* Test posts. Please test in a newsgroup meant for testing,
such as alt.test.

news.groups.questions is a good place to ask about the appropriate
newsgroup for a given topic.

 

[Malcolm]

Sorry for the lame question but, what's the difference between
Debug and Release versions?

Its compiler-specific. Because of the way debuggers work, it is often useful
to have two compilation schemes, one to provide the optimal environment for
the debugger, and one to produce the smallest and fastest possible
executable for release. For instance, if the optimiser collapses several
nested functions into one, it is usually very difficult for the debugger to
tell in which function an illegal operation occurred, so this optimisation
won't be performed for the "debug" build.

Another optimisation is with memory management. Under debug memory returned
from malloc() is often set to a pattern like CECE which is designed to be
easily recognisable, and to produce large negative numbers - obvious garbage
and highly likely to cause address errors if used to calcualte arrays. This
makes sense, since you want to pick up errors. Under release, however, you
want to suppress errors if they exist, so malloc() can return memory
initialised to zero. Similarly, free() under debug should shred garbage,
whlst under release it shouldn't, so that if the program accidentally
references freed memory it has a sporting chance of recovery.

These rules apply to games, where you want to avoid a crash at all costs. In
safety-critical code a suppress errors aproach isn't acceptable.

 

[Peter Nilsson]

Your question is outside the domain of comp.lang.c, ...

I disagree. The broader aspects yes, but C does have <assert.h>. The difference between a
debug and release version can be made in terms of NDEBUG.

 

[CBFalconer]

I disagree. The broader aspects yes, but C does have <assert.h>.
The difference between a debug and release version can be made
in terms of NDEBUG.

AFAIK the only thing NDEBUG affects is the assert macro in
assert.h. That doesn't prevent the user examining or setting its
value, however. The OP is probably thinking about the way the MSC
IDE works, which is very far off topic here, and he should to to a
Microsoft newsgroup of some kind.

 

[Malcolm]

The OP is probably thinking about the way the MSC
IDE works, which is very far off topic here, and he should to to > a

Microsoft newsgroup of some kind.MSC isn't "very far off topic", as a discussion of, say, knitting would be.
It's a related topic that falls out of the boundaries of the group, like,
say, prime number determining algorithms.

However the release and debug builds are a function of the compiler, they
just happen to be set by options in the IDE. A description of exactly what
the MS compiler does is too specific for comp.lang.c, but a general
discussion of why compilers often provide debug and release options is I
think reasonably on-topic.

 

[EventHelix.com]

Typically, a Debug release would define a flag like _DEBUG in the
make file. This will include assert and other macros in the final
code.

In the release mode, _DEBUG would not be defined. And the assert
macros will map to blank.

The following article provides an example:

http://www.eventhelix.com/RealtimeMantra/Object_Oriented/design_by_contract.htm

Sandeep

 

[Randy Howard]

In the release mode, _DEBUG would not be defined. And the assert
macros will map to blank.

You might want to look up NDEBUG instead.