8

Possible Duplicate:
Debug/Release difference

I want to know what do these two mean: Debug build and Release build and what is the difference between both.

Which one should I use (I mean which are the suitable conditions for each one) and which build actually I am using now if I make a simple C++ project in Visual studio. [If I do not change any projects settings]

I am asking this because I am trying to make a GUI using wxWidgets 2.9.4 and they give different case of adding required .lib. these are

release ANSI static

debug ANSI static

release Unicode static

debug Unicode static

Please put a detailed answer.

Elletlar
  • 3,136
  • 7
  • 32
  • 38
Natwar Singh
  • 2,197
  • 4
  • 26
  • 42
  • No, I don't give a detailed answer. http://haacked.com/archive/2004/02/14/difference-between-debug-vs-release-build.aspx . – Jakob S. Aug 09 '12 at 12:07
  • 1
    what did you investigate yourself? Have you tried to google for "Debug vs Release"? – default Aug 09 '12 at 12:07
  • 1
    @ Jakob S: but it is .net this is c++ – huseyin tugrul buyukisik Aug 09 '12 at 12:12
  • 1
    @tuğrulbüyükışık While the language differs, the difference between debug and release builds does not. – Some programmer dude Aug 09 '12 at 12:14
  • then what are we waiting for? Lets flag it! – huseyin tugrul buyukisik Aug 09 '12 at 12:15
  • 2
    @JoachimPileborg it does. C++ removes far more information in Release mode compared to .NET / Java. Sometimes you even can't inspect the value of a variable because it was optimized away by the compiler. – Tobias Langner Aug 09 '12 at 12:21
  • @TobiasLangner That depends on the values of your optimization flags, _not_ some arbitrary name you give the build. (Most applications should only be build in one mode anyway.) – James Kanze Aug 09 '12 at 12:37
  • @JamesKanze although you are right, it depends on the flag, a release build has normally full optimization on where debug has none. As far as I know, most of the optimizations that make debugging difficult in C++ - Release, are done by the JIT in C#. So there's a major difference because of the structure of the compilation ( Compile + Link in C++ vs. Compile/Link to bytecode & JIT afterwards where you can check whether a debugger is present or not). – Tobias Langner Aug 10 '12 at 06:36
  • @TobiasLangner Most projects I've worked haven't had multiple configurations; we delivered the exact binaries we used in development. This _should_ be the usual situation, only varied from when performance constraints force optimizations which aren't compatible with debugging. (And even then, ideally, only the critical parts would be optimized. But that's not always trivial to implement with the usual build systems.) Conventionally, "release" refers to the configuration you use to deliver, and "debug" to something else, _if_ there is a difference. – James Kanze Aug 10 '12 at 08:05

4 Answers4

29

Debug build and release build are just names. They don't mean anything.

Depending on your application, you may build it in one, two or more different ways, using different combinations of compiler and linker options. Most applications should only be build in a single version: you test and debug exactly the same program that the clients use. In some cases, it may be more practical to use two different builds: overall, client code needs optimization, for performance reasons, but you don't want optimization when debugging. And then there are cases where full debugging (i.e. iterator validation, etc.) may result in code that is too slow even for algorithm debugging, so you'll have a build with full debugging checks, one with no optimization, but no iterator debugging, and one with optimization.

Anytime you start on an application, you have to decide what options you need, and create the corresponding builds. You can call them whatever you want.

With regards to external libraries (like wxwidgets): all compilers have some incompatibilities when different options are used. So people who deliver libraries (other than in source form) have to provide several different versions, depending on a number of issues:

  • release vs. debug: the release version will have been compiled with a set of more or less standard optimization options (and no iterator debugging); the debug version without optimization, and with iterator debugging. Whether iterator debugging is present or not is one thing which typically breaks binary compatibility. The library vendor should document which options are compatible with each version.

  • ANSI vs. Unicode: this probably means narrow char vs wide wchar_t for character data. Use which ever one corresponds to what you use in your application. (Note that the difference between these two is much more than just some compiler switches. You often need radically different code, and handling Unicode correctly in all cases is far from trivial; an application which truly supports Unicode must be aware of things like composing characters or bidirectional writing.)

  • static vs. dynamic: this determines how the library is linked and loaded. Usually, you'll want static, at least if you count on deploying your application on other machines than the one you develop it on. But this also depends on licensing issues: if you need a license for each machine where the library is deployed, it might make more sense to use dynamic.

James Kanze
  • 150,581
  • 18
  • 184
  • 329
  • thanks for writting a detailed answer , now i get which one should i use. Thanks.. – Natwar Singh Aug 09 '12 at 16:09
  • 2
    Thank you. Now I understand the issue fully. There is no 'magic' in the debug build. Just different compiler and linker options/flags. So if I compile a program with GCC and -g flag, there is no performance penalty. It just means that the debugging symbols are included in the resulting file. Performance penalty comes from different flags like -D (and which flags your program or underlying libraries when compiled take into account) and options like -O for the optimization and so on. – Marko Kukovec Sep 20 '13 at 11:03
  • 1
    `-g` will technically have a slight performance degradation because the binaries are larger, but you're right--it's the `O` and some `D` flags that make the difference. – Russell Greene Feb 24 '17 at 01:35
9

When doing a DEBUG build the project is set up to not optimize (or only very lightly optimize) the generated code, and to tell the compiler to add debug information (which includes information about functions, variables, and other information needed for debugging). The pre-processor is set up to define the _DEBUG macro.

A RELEASE build on the other hand have higher level of optimization, and no debug information is saved. The pre-processor is set up to define the NDEBUG macro.

Another difference is that certain "system" macros, for example ASSERT-like macros, do different things depending on if _DEBUG or NDEBUG is defined. ASSERT does nothing in a release build, but does checks and abort in debug builds.

The difference between Unicode and non-Unicode is mostly the UNICODE pre-processor macro, which tells header files if certain Unicode functionality should be enabled or not. One thing is that TCHAR will be defined to wchar_t in Unicode builds but as char in non-Unicode builds.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
3

In the debug build you get a lot more error checjking, so if something goes wrong you may get a more informative message ( and it will run more slowly )

In the debug build you will get more information when you run it under the debugger.

You can tell if the build is debug build by looking at the preprocessor definitions of the project properties: _DEBUG will be defined.

You will send the release build to your clients. ( The debug build uses the debug libraries which are not present on most non development machines )

ravenspoint
  • 19,093
  • 6
  • 57
  • 103
  • You get what you ask for. You can turn off optimization in "release" mode, and you can turn it on in "debug" mode. The modes are just names, and aren't really relevant for most applications. – James Kanze Aug 09 '12 at 12:33
  • It is a good idea to always turn off optimization in debug - otherwise things get very confusing when you use the debugger to step through the code. – ravenspoint Aug 09 '12 at 12:37
3

if you want to link a static library to a project, it needs to be compiled with the same settings that you use to compile your code. That's why there is a Debug & a Release version of the library. Additionally, you need to specify whether you want to use unicode or ansi. Here the answer is quite simple (in my opinion) - just use unicode.

What is different in Release compared to Debug so that they can't mix? Mainly it's the memory management. The memory management in Debug does a lot of additional things to allow you to find errors early. As an example, there are canaries that can be checked for overwriting of code. Uninitialized memory is initialized with a specific pattern, ... Additionally, there are a lot of optimizations in release that are not used in debug. This allows release to run faster but makes it difficult to debug the code. Methods might get optimized away and instead are inlined, the parameter passing may be optimized to use registers, ...

So in C++ you manage (at least) 2 configurations. One Debug configuration that you link with the debug library. This one is for developing & testing. And a Release configuration linked with the release library. This one is for delivery. But don't forget that you need to test Release as well as it might behave differently than the Debug configuration.

Tobias Langner
  • 10,634
  • 6
  • 46
  • 76
  • "just use Unicode"---only if you need it. Unicode is a lot more complex than plain ANSI, and while it's necessary if you plan on using the program in places not covered by a single byte encoding (e.g. most of Asia), it does require a lot more effort. – James Kanze Aug 09 '12 at 12:35
  • there's not much more effort to it - especially since all API functions on modern windows require unicode strings anyway. I agree, there's much more effort if you really want to translate stuff - but that doesn't depend on the fact that you use std::wstring and wchar_t* instead of std::string and char* – Tobias Langner Aug 10 '12 at 06:39
  • I agree that it's no more difficult to use `wchar_t` than it is to use `char`. But "using Unicode" entails a lot more than just using `wchar_t`; and there's no point in using `wchar_t` _unless_ you're using Unicode (or you're working in a language which does require more than 256 characters). It's just added complexity for nothing. (For that matter, unless I's transforming the text, I'll use `char` and UTF-8 even for Unicode. It makes things a lot simpler.) – James Kanze Aug 10 '12 at 08:13
  • And re the system interface under Windows... Whatever Windows pretends to do, it can't change the world. And the modern world is 8 bit oriented, starting with the Internet. Windows carefully makes both 8 and 16 bit interfaces available; using the 16 bit one paints you into a corner, and means that you cannot ever communicate with any thing else, or port your code to anything else. It may be justified for some GUI applications, but not generally. – James Kanze Aug 10 '12 at 08:16
  • "As an example, there are canaries that can be checked for overwriting of code. Uninitialized memory is initialized with a specific pattern" . This is exactly what i was looking for. Can you clarify what is a canary here? And any other examples? – Mudit Jain Apr 03 '18 at 22:58