what does mean by debug build and release build, difference and uses

Question

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.

Answer 1

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.