delete this;

innerhalb einer Klasse noch den aktuellen Thread mit ExitThread(); verlassen? Oder wird dadurch der Thread schon automatisch beenden? Oder ist das gar nicht möglich?

Hm, sollte klappen, wenn du das im Konstruktor der Klasse behandelst.

Das passiert nicht im Konstruktor, sondern beim Verlust einer Client-Verbindung.

phlox81 schrieb:

Der sauberste Weg ist es mit Sicherheit aber nicht...

Wie geht es besser?

phlox81 schrieb:

Hm, sollte klappen, wenn du das im Konstruktor der Klasse behandelst.

Das passiert nicht im Konstruktor, sondern beim Verlust einer Client-Verbindung.

phlox81 schrieb:

Der sauberste Weg ist es mit Sicherheit aber nicht...

Wie geht es besser?

Ich meinte nicht den Konstruktor sondern den Destruktor.
Ich meinte damit, das du ExitThread vor delete this aufrufst, oder im Destruktor.

Am besten zeigst du mal ein wenig mehr Code.

Wenn ich ExitThread(); vor delete this; aufrufe, wird das Selfdelete ja gar nicht mehr ausgeführt um in den Destructor kann ich ExitThread(); auch nicht schieben, weil das Objekt auch von außen an anderer Stelle gelöscht wird und sonst ein Thread beendet werden würde, der eigentlich noch weiter laufen würde.

void Foo::Bar()
{
    DWORD exitCode = this->DetermineExitCode();
    delete this;
    ::ExitThread(exitCode);
}

Wichtig ist bloss dass du "this" nach dem "delete this" nichtmehr dereferenzierst, nicht explizit und auch nicht implizit. Da ExitThread aber "this" nicht braucht, ist das OK.
Blöd ist nur dass ExitThread kein stack-unwinding macht, und das kann durchaus ein Problem darstellen je nachdem von wo aus "Bar" aufgerufen wird.

Besser wäre es wohl den Thread irgendwie "kontrolliert" zu beenden, also z.B. irgendeine Exception zu werfen die per definitionem nirgends gefangen wird.

...
Wichtig ist bloss dass du "this" nach dem "delete this" nichtmehr dereferenzierst, nicht explizit und auch nicht implizit. Da ExitThread aber "this" nicht braucht, ist das OK....

hustbaer schrieb:

...
Blöd ist nur dass ExitThread kein stack-unwinding macht, ...

Naja, wenn Zweiteres nicht wäre, wäre Ersteres vermutlich nicht mehr gegeben, oder ?

Ich stimme Dir zu: Ich denke, das sollte man anders/besser lösen (Da sich einen Klasse nicht selbst erzeugt, sollte sie sich auch nicht selbst vernichten)...

Gruß,

Simon2.

Nur noch eine Frage: wenn ein Thread mit TerminateThread() beendet wird, werden dann die Variablen, die normal mit int a; oder so angelegt wurden, wieder freigegeben oder bleiben die im Speicher liegen?

Da recv() aber blockt, wüßte ich gerne, wie man die Verbindung von außen kappt, so daß der Thread sich selbst normal beenden kann.

P.S.
Hallo "Dr. C++":
Wenn die Verbindung von außen geschlossen wird, so gibt recv() 0 zurück bzw. einen der vordefinierten Stati (z.B. WSAECONNRESET, WSAECONNABORTED oder WSAESHUTDOWN).

Edit: Ich sehe gerade, daß im MSDN-Beispiel ein Fehler ist (wo ich die Infos herhabe). Die Funktion WSAGetLastError() gibt einen der definierten Fehlerwerte zurück, wenn recv() SOCKET_ERROR (-1) zurückgibt.

hustbaer schrieb:

...
Wichtig ist bloss dass du "this" nach dem "delete this" nichtmehr dereferenzierst, nicht explizit und auch nicht implizit. Da ExitThread aber "this" nicht braucht, ist das OK....

hustbaer schrieb:

...
Blöd ist nur dass ExitThread kein stack-unwinding macht, ...

Naja, wenn Zweiteres nicht wäre, wäre Ersteres vermutlich nicht mehr gegeben, oder ?

Ich stimme Dir zu: Ich denke, das sollte man anders/besser lösen (Da sich einen Klasse nicht selbst erzeugt, sollte sie sich auch nicht selbst vernichten)...

Gruß,

Simon2.

Fix sakrament, wieso werden mir hier ständig die Worte im Mund verdreht. Ich habe nichts dagegen wenn sich Objekte selbst löschen, so wie z.B. in COM ist das vollkommen OK. Ich habe nur was dagegen einen Thread abzuschiessen der noch Objekte rumliegen hat.

BTW: Wenn ExitThread stack unwinding machen würde, dann bräuchte man das ganze "delete this" nicht, d.h. es wäre auch kein Problem.

----

@Dr. C++ : kapsel doch die Socket Verbindung in eine Klasse, und bring' der bei Exceptions zu werden wenn ein Socket Call fehlschlägt. Damit fliegt automatisch aus send/recv eine Exception raus wenn die Verbindung getrennt wrude, und das Problem ist gegessen.

Es ist auf jeden Fall eine ganz schlechte angewohnheit unsaubere Lösungen mit "ja aber" zu rechtfertigen, so wie in "ja, aber die saubere Lösung wäre ja so viel Arbeit".

@Dr. C++ : kapsel doch die Socket Verbindung in eine Klasse, und bring' der bei Exceptions zu werden wenn ein Socket Call fehlschlägt. Damit fliegt automatisch aus send/recv eine Exception raus wenn die Verbindung getrennt wrude, und das Problem ist gegessen.

Die Socket-Verbindungen sind bereits in einer Klasse untergebracht. Und mit den Exceptions: müsste ich dann um den ganzen "eigentlichen" Code ein try schreiben und darunter nur ein catch, das den Thread mit einem einfachen return beendet?!

Und mit den Exceptions: müsste ich dann um den ganzen "eigentlichen" Code ein try schreiben und darunter nur ein catch, das den Thread mit einem einfachen return beendet?!

Kurz: Ja.

...
Fix sakrament, wieso werden mir hier ständig die Worte im Mund verdreht....

Sorry, dann hatte ich Dein Posting mißverstanden.
Also: Die Abneigung von "selbstlöschenden Objekten" ist meine ganz private eigene Meinung und hat nix mit hustbaer zu tun.

Sorry,

Simon2.

Nachtrag:

hustbaer schrieb:

...
BTW: Wenn ExitThread stack unwinding machen würde, dann bräuchte man das ganze "delete this" nicht, d.h. es wäre auch kein Problem.
...

Hmmmm vielleicht habe ich es noch nicht richtig begriffen, aber "delete this" brauche ich doch nur für Heapobjekte, die durch stack unwinding nicht automatisch abgeräumt werden .... oder hattest Du dann Destruktoren einer kapselnden Klasse im Sinn ?