Thread: _beginthreadex does not complile

Oh I see, thank you.

But tell me, what are the differences between the debug and release builds?

there is a number of differences
you can search inet
For example:
http://www.flounder.com/debug_release.htm

For everyone's reference:

Creating and Managing Visual C++ Projects

Using Projects to Build Applications

C Run-Time Libraries

gg

Originally Posted by vart

When you create project in VS2003 you already have 2 build "release" and "debug"

When you enter Project Properties in the "Configuration" combo you will see Active(Debug) for example

You can choose then the build you want and change settings for this build

If you choose Release - select Multithreaded RunTime
If you choose Debug - select MultiThreaded Debug RunTime

Then only select the suitable build (combo on the standard toolbar) when you compile and link the exe

Ok, so if I understand this correctly, the Release mode is an optimized version of the program, while Debug mode is the program as it was written?

Also, what is the point of using Debug, why not use Release directly?
It just seems like double work, no?

No, it's no additional work at all for you, unless you consider flipping a compiler switch and waiting for it to compile again work.

The debug version has its reason for existence in its name: debugging. Debug versions often contain additional code (behind the scenes, you usually don't notice it, unless you write debug code like assertions yourself, which you should) that do some sanity checking. That is, although you absolutely know a pointer can't be NULL, the debug version might check anyway, because there might be a bug somewhere that causes it to be NULL regardless. In release, this check is not there to improve performance.
The other part is that after optimization, it can be very hard to map the execution status back to the source code, so line-by-line debugging is not possible with a release build. The debug build does not reorder instructions or apply any other optimizations, so mapping to source is rather easy.
And of course, debug builds contain debug information. Every bit of program code has embedded annotations as to where it came from: which source file, which source line, how the variables where mapped to registers and memory regions, all that stuff that is usually lost in compilation. That's the main reason why debug versions are so much bigger than release versions. (We're talking factor 20 - 100 size increase here.)

But it seems like the debug version creates a false reality, like the NULL example you just provided.

It just seems like twice the work to detect problem, because something that works great in the Debug mode, might crash with the release version of the program.

Originally Posted by Devil Panther

But it seems like the debug version creates a false reality, like the NULL example you just provided.

It just seems like twice the work to detect problem, because something that works great in the Debug mode, might crash with the release version of the program.

In most cases you will start working with release.
When release crashes - you create debug version and try to debug it.
If debug works fine - you know that the problem lies in the difference between debug and release - you start applying different technics for locating the problem (like building release build with debug info included, tracing etc)...

But in most cases the problem that occured in release version occures also in debug, so using debugger with debug version greatly speeds up the process of locating the problem

So it's recomended to start the project with the Release mode, and if needed switch to Debug.

Thank you all for your time and help.