Thread: Compile Errors for CreateThread..

Another thing: if you use the C runtime at all, you should use __beginthreadex instead of CreateThread to start the new thread. It's defined in <process.h>.

Another thing: if you use the C runtime at all, you should use __beginthreadex instead of CreateThread to start the new thread. It's defined in <process.h>.

Why? CreateThread is a Win32 API call, so that's what you are meant to use in Windows.

Because _beginthreadex does some extra initializing before calling CreateThread in turn, and also some cleanup before the thread finishes. If you use CreateThread directly, and then any CRT function that uses thread-local resources (quite a few of them), you leak resources for every thread that dies.

(I got the name wrong, though: it's only a single underscore in front.)

It's documented in msdn and I'm fairly sure it's also mentioned in either (or both) Petzold's 'Windows Programming' or Richter's 'Programming Applications for MS Windows'.

Originally Posted by msdn,CreateThread

A thread in an executable that calls the C run-time library (CRT) should use the _beginthreadex and _endthreadex functions for thread management rather than CreateThread and ExitThread; this requires the use of the multi-threaded version of the CRT. If a thread created using CreateThread calls the CRT, the CRT may terminate the process in low-memory conditions.

Petzold uses _beginthread, which is fine for some uses, but provides fewer options. It is also paired with _endthread (which a thread created with _beginthread calls automatically upon ending!), which does not allow you to retrieve the thread exit code, because it closes the thread handle and, because _beginthread does not permit the creation of a sleeping thread, prevents the existence of a reliable way of duplicating it first. It's Richter who points out the problems and strongly recommends _beginthreadex over _beginthread.
Richter also has this to say about using CreateThread instead of _beginthreadex (paraphrased, translating back to English from my German version):

Of course, a few problems remain. For example, the entire process is terminated if the thread calls the C/C++ runtime function signal, because the environment is not prepared for structured exception handling. In addition, if the thread ends without a call to _endthreadex, the data block [for the CRT thread-local data] cannot be freed, resulting in a memory leak. (And who would call _endthreadex for a thread created with CreateThread?)

the data block [for the CRT thread-local data] cannot be freed

If CreateThread threads would never free data, it would cause many many problems. I haven't seen these problems and that's why I don't believe this part.