Probleme mit erstellen von Threads

evilissimo

makro-auflöser schrieb:

so gibt es ab x64 z.B. gar kein __stdcall mehr

Ich hoffe es wird dann einfach nur ignoriert vom 64-Bit Compiler.

MfG,
Ranner

Laut einem Artikel den ich im MSDN Magazin gelesen habe soll das so sein

Ehrlich gesagt finde ich es gut, dass das dann ignoriert wird und das es nur noch eine Art der Aufrufkonvention gibt.

Es gibt damit einige Bugs weniger die durch vergessenes Angeben der Aufrufkonvention aufgetreten sind.

Ich hab da auch gelesen das die Aufrufkonvention auf dem x86_64 dann der __fastcall Aufrufkonvention ähneln soll.

BR

groovemaster

AceKiller73 schrieb:

Problem ist immer noch da:
Ich denke ich benutze irgendwo falsche typen oder so aber
ich weiß nicht was der fehler genau ist

Du übergibst eine Funktion vom Typ

DWORD WINAPI (All::*)(void*)

CreateThread erwartet aber eine Funktion mit folgender Signatur

DWORD WINAPI ThreadProc(void*)

Denk nochmal darüber nach, dann wird dir schnell klar, warum es nicht funktioniert.

evilissimo

Probier es mal so:

class All
{
public:
        static DWORD WINAPI NewThread(void *param)
        {
                return 1;
        }
        bool Create()
        {
        CreateThread(0,0,reinterpret_cast<LPTHREAD_START_ROUTINE>(&All::NewThread),0,0,0);
        return true;
        }
};

BR

evilissimo

Ranner schrieb:

makro-auflöser schrieb:

so gibt es ab x64 z.B. gar kein __stdcall mehr

Ich hoffe es wird dann einfach nur ignoriert vom 64-Bit Compiler.

MfG,
Ranner

Ich poste nie solche Idiotie, unterlasse es mit dem Namen eines Großen zu unterschreiben, Kleiner.

MfG,
Ranner

Tja die Idiotie ist aber keine. :p

Einen Cast nach LPTHREAD_START_ROUTINE braucht man nie!!

Und den Zeiger auf die Thread-ID würde ich auf jeden Fall übergeben damit es nicht unter Windows 98 abstürzt.

evilissimo

....... schrieb:

Einen Cast nach LPTHREAD_START_ROUTINE braucht man nie!!

Wenn man keinen Bock auf langweilige Warnungen hat schon

BR

Wenn ohne den Cast Warnungen kommen hast du was falsch gemacht.

evilissimo

Hmm ok. Ich gebs zu, ich habe mich getäuscht *fg*

Ich habs grad mal getestet.

*g*

BR

Jochen Kalmbach

Also bei mir kommen da keine Warnungen:

#include <windows.h>

class Foo
{
  static DWORD WINAPI Bar(LPVOID pData)
  {
    return 0;
  }
  void StartThread()
  {
    DWORD dwThreadId;
    CreateThread(NULL, 0, Bar, NULL, 0, &dwThreadId);
  }
};

Aber wie gesagt> Besser w're>

#include <process.h>

class Foo
{
  static void Bar(void* pData)
  {
  }
  void StartThread()
  {
    _beginthread(Bar2, 0, NULL);
  }
};

evilissimo

Jochen Kalmbach schrieb:

Also bei mir kommen da keine Warnungen:

#include <windows.h>

class Foo
{
  static DWORD WINAPI Bar(LPVOID pData)
  {
    return 0;
  }
  void StartThread()
  {
    DWORD dwThreadId;
    CreateThread(NULL, 0, Bar, NULL, 0, &dwThreadId);
  }
};

Ich hab ja gesagt das ich mich getäuscht habe

BR

Jochen Kalmbach

evilissimo schrieb:

Ich hab ja gesagt das ich mich getäuscht habe

Sorry! Ich hab Dich dann falsch verstanden...

AceKiller73

Also erstmal serh vielen Dank an Alle.

@jochen geht alles jetzt danke. ach und beginthread ist doch
eine VC Funktion ich will aber direkt an der API programmieren. Oder gibt
es irgendwelche Vorteile außer das der Speicher aufgeräumt wird?
@All nur um es mal zu wissen. Was ist ein "cast"?

Many thx nochmal

MFG
Ace

Was meinst du mit VC Funktion??? Der Jochen hats doch schon erklärt, wenn du die CRT benutzt (Was du bestimmt tust!!) dann solltest du _beginthread(ex) benutzen.

MfG,
*Ranner*

CodeFinder

AceKiller73 schrieb:

@All nur um es mal zu wissen. Was ist ein "cast"?

Das sind Grundlagen... ->

C: http://tutorial.schornboeck.net/casts.htm

C++: http://de.geocities.com/throni3/cpp/Kapitel_25.html

Wenn Sie beabsichtigen, C-Laufzeitroutinen von einem Programm aus aufzurufen, das mit Libcmt.lib erstellt wurde, müssen Sie die Threads über die _beginthread-Funktion oder über die _beginthreadex-Funktion starten. Verwenden Sie nicht die Win32-Funktionen ExitThread und CreateThread. Bei der Verwendung von SuspendThread tritt möglicherweise ein Deadlock auf, wenn mehrere blockierte Threads darauf warten, dass der unterbrochene Thread den Zugriffsvorgang auf eine C-Laufzeitdatenstruktur abschließt.