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.