When writing thread functions today, it is found that the definition of ThreadProc is required in MSDN: DWORD WINAPI THREADPROC (LPVOID LPPARETER);
Do not solve why use the WinAPI macro to define it, and find out the definition below. Ever need to distinguish the difference between the two __stdcall and __cdecl; #define CALLBACK __stdcall #define WINAPI __stdcall #define WINAPIV __cdecl #define APIENTRY WINAPI #define APIPRIVATE __stdcall #define PASCAL __stdcall #define cdecl _cdecl #ifndef CDECL #define CDECL _cdecl # ENDIF
Almost every Windows API function we wrote is __stdcall type, first, you need to know the difference between the two: The stack needs to be used when the Windows function is called (STACK, a storing structure). When the function call is completed, the stack needs to be clear, here is the key to the problem, how to clear it? ? If our function uses _cdecl, then the stack clearance is made by the caller, using COM's terminology is the customer. This brings a tricky problem. Different compilers have the same way, whether the caller can complete the clearance work? The answer cannot be. If you use __stdcall, the above problem is solved, and the function addresses yourself to clear your job. Therefore, in the call of the cross-(development) platform, we use __stdcall (although sometimes it appears in WinAPI). So why still need _cdecl? When we encounter such a function such as fprintf (), it is variable, unregulated, and the caller cannot know the length of the parameters in advance, and after the removal work is not working properly, so we only Can use _cdecl. Here we have a conclusion, if there is no variable parameters in your program, it is best to use the __stdcall keyword.
