🚀 go-pugleaf

I suggest that _beginthread or _beginthreadNT be used instead of 
CreateThread.  While CreateThread works correctly, the use of one of the 
other two functions is required for proper operation of the runtime library.

You MIGHT get away with CreateThread but it is more likely that the program 
would display serious problems that are difficult to track down because they 
only appear at irregular intervals.

_beginthread and _beginthreadNT are documented in the compiler's help.

.  Ed

> Thomas Maeder wrote in message
> news:m2zmngr8wf.fsf@madbox2.Arbeitsgruppe...
>
> That's what I'd try:
>
> CreateThread() is declared like this:
>
> HANDLE CreateThread(
>  LPSECURITY_ATTRIBUTES lpThreadAttributes,
>  SIZE_T dwStackSize,
>  LPTHREAD_START_ROUTINE lpStartAddress,
>  LPVOID lpParameter,
>  DWORD dwCreationFlags,
>  LPDWORD lpThreadId
> );
>
> lpStartAddress can be used to pass the address of the callback
> function, and lpParameter for the address of the callback object.
>
> So something like this should work:
>
> class ThreadFunction
> {
>  public:
>    virtual DWORD execute() = 0;
>
>    HANDLE startThread();
> };
>
> DWORD WINAPI callbackFct(LPVOID lpParameter)
> {
>  assert(lpParameter!=0);
>  ThreadFunction *tf(static_cast<ThreadFunction *>(lpParameter));
>  return tf->execute();
> }
>
> HANDLE ThreadFunction::startThread()
> {
>  return CreateThread(a1,a2,&callbackFct,this,a3,a4);
>  // for some appropriate a1..a4
> }
>
> Since the function called back is to return a DWORD, I think that
> should also be the return type of execute().
>
> callbackFct is the proxy function. Technically, it can't be a static
> member of a class (although you may get away with one using most
> implementations), but it can well be a non-member function defined in
> the unnamed namespace of the translation unit defining
> ThreadFunction::startThread().