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

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.

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.

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 )