3. virtual Thread in class

virtual Thread in class

  • K
     

    class Callback
{
public:
    virtual DWORD run() = 0;
protected:
    ~Callback() {}
};

    Iiiiii ... 🙂
    Nachteil: Ich kann keine beliebige Funktion/Member als Thread laufen lassen, ich muss ableiten, ich muss das Interface respektieren.

    Hier eine C++03-Variante aehnlich std::thread: http://ideone.com/gQfRCV , nutzt pthread, kann aber durch die Windows-Funktionen ersetzt werden.

    0
  • T

    @knivil: Ja, das ist auch eine Lösung.

    0
  • C

    theta schrieb:

    Was ist SecondRunWindow ?

    Etwas das von RunWindow ableitet, wie ich bereits im ersten Post geschrieben hatte... (Und was soll es sonst sein, es ist implizit in RunWindow umwandelbar...)

    0
  • T

    cooky451 schrieb:

    theta schrieb:

    Was ist SecondRunWindow ?

    Etwas das von RunWindow ableitet, wie ich bereits im ersten Post geschrieben hatte... (Und was soll es sonst sein, es ist implizit in RunWindow umwandelbar...)

    Dann würde ich erwarten, dass RunWindow entweder einen public virtual oder einen protected non-virtual Destructor hat. Und das aus dem Grund, weil es dafür gedacht ist als Klasse in einer Basisklassen Liste zu stehen. Wenn es nicht dafür gedacht ist, dann nicht.

    0
  • C

    Es ist einfach eine unnötige Fehlerquelle, weil diese Optimierung hier nichts bringt. (Und jetzt schreib bitte nicht wieder es sei keine Optimierung, einen Destruktor einer Basisklasse nicht virtual zu machen ist natürlich eine.)

    0
  • M

    cooky451 schrieb:

    delete rw; // UB, da Destruktor nicht virtual.

    Nein, kein UB. Compilerfehler, da der Destruktor protected ist. Lies den gotw.

    0
  • C

    MFK schrieb:

    Nein, kein UB. Compilerfehler, da der Destruktor protected ist. Lies den gotw.

    0
  • M

    cooky451 schrieb:

    Dein Beispiel verstößt gegen die Empfehlung, dass eine Basisklasse einen public virtual oder protected nonvirtual Destruktor haben sollte. Wenn man sich an diese Empfehlung hält, erzeugt dein Beispiel kein UB.

    0
  • T

    MFK schrieb:

    cooky451 schrieb:

    Dein Beispiel verstößt gegen die Empfehlung, dass eine Basisklasse einen public virtual oder protected nonvirtual Destruktor haben sollte. Wenn man sich an diese Empfehlung hält, erzeugt dein Beispiel kein UB.

    👍

    0
  • C

    MFK schrieb:

    Dein Beispiel verstößt gegen die Empfehlung, dass eine Basisklasse einen public virtual oder protected nonvirtual Destruktor haben sollte. Wenn man sich an diese Empfehlung hält, erzeugt dein Beispiel kein UB.

    Natürlich verstößt es dagegen, aber so etwas lässt sich eben trotzdem ganz einfach und ohne Nachteil verhindern, ohne dass es auf den User abgeschoben wird, das war der Punkt des Beispiels.

    0
  • M

    cooky451 schrieb:

    Natürlich verstößt es dagegen, aber so etwas lässt sich eben trotzdem ganz einfach und ohne Nachteil verhindern, ohne dass es auf den User abgeschoben wird.

    D.h. jeder Klasse reflexartig einen leeren public virtual Destruktor verpassen, für den Fall, dass ein User auf die Idee kommen könnte, davon abzuleiten? Bzw. ihm durch eben diesen public virtual Destruktor auch noch zu signalisieren, dass die Klasse dafür gedacht ist? Ich weiß ja nicht.

    Aber jetzt haben wir ja final.

    0
  • C

    MFK schrieb:

    D.h. jeder Klasse reflexartig einen leeren public virtual Destruktor verpassen, für den Fall, dass ein User auf die Idee kommen könnte, davon abzuleiten? Bzw. ihm durch eben diesen public virtual Destruktor auch noch zu signalisieren, dass die Klasse dafür gedacht ist? Ich weiß ja nicht.

    Nein, aber eine Klasse von der man ableiten soll (dafür ist Callback ja gedacht), und die außerdem bereits eine virtuelle Funktion hat, sollte einen virtuellen Destruktor haben.

    0
Anmelden zum Antworten