"pure virtual destructor"

[besserwisser]

wieso will man erzwingen, dass eine klasse abstrakt ist? damit's schön aussieht, oder hat das einen technischen grund? die fehlende möglichkeit der instanzierung einer abstrakten klasse ist kein argument, da man das auch mit protected ctors schafft.

pure virtual dtors, die durch die default dtors in den abgeleiteten klassen implementiert werden, erzeugt eine inkonsistenz beim begriff "pure virtual". protected dtors erzeugen keine inkonsistenzen.

[ghorst]

warum sollte man jemanden zwingen einen dtor neu als public zu definieren? wenn man eine klasse hat, die nur raii-container und pod als daten hat, wäre das schließlich überflüssig.

oder anders: es ist geschmackssache.

[besserwisser]

ghorst schrieb:

warum sollte man jemanden zwingen einen dtor neu als public zu definieren?

sorry. ich hab mich einmal verschrieben. es sollte lauten: "protected ctors erzeugen keine inkonsistenzen." ctors. nicht dtors. man sollte wohl nicht so viel abkürzen

[asc]

besserwisser schrieb:

wieso will man erzwingen, dass eine klasse abstrakt ist? damit's schön aussieht, oder hat das einen technischen grund? die fehlende möglichkeit der instanzierung einer abstrakten klasse ist kein argument, da man das auch mit protected ctors schafft.

1. Weil es die übliche C++ Vorgehensweise ist?
2. Um auch anderen im Projekt sofort sichtbar zu machen das dies nur als Basisklasse gedacht ist (Es kann ja sonst vielleicht noch einer auf den Gedanken kommen eine Factorymethode zur Verfügung zu stellen)

Kurz gesagt: es ist eindeutiger.

[besserwisser]

asc schrieb:

1. Weil es die übliche C++ Vorgehensweise ist?
2. Um auch anderen im Projekt sofort sichtbar zu machen das dies nur als Basisklasse gedacht ist (Es kann ja sonst vielleicht noch einer auf den Gedanken kommen eine Factorymethode zur Verfügung zu stellen)

1: damit es also wirklich schöner aussieht.
2: das kann aber ebenso ein nachteil sein. außerdem muss die factory methode sowieso als teil der klasse deklariert werden. damit ist maximal der ersteller der klasse auch der, der die factory methode schreibt und nicht jemand externer.

ich will ja nicht behaupten, dass die methode mit dem pure virtual dtor grundsätzlich schlecht wäre. sie widerspricht nur einfach dem begriff pure virtual.

die günstigere lösung wäre gewesen, das wort schlüsselwort abstract einzufühen. es hätte statt pure virtual für methoden verwendet und vor die klasse selbst geschrieben werden können. das würde irgendwelche hacks bezüglich des dtors unnötig machen und eine klasse klar als abstrakt deklarieren.
mir ist schon klar, dass das zuweisen der 0 zu einer virtual methode die symbolik hat, 0 an diese stelle der vtable zu schreiben. ich bin aber der meinung, dass man mehr auf leserlichkeit und weniger auf symbolik wert legen sollte.

aber ok, das wird ein glaubenskrieg und ich will mich hier mit den c++ soldaten nicht anlegen. das artet schnell in schlachten aus. das war nur mein senf dazu.

[pumuckl]

besserwisser schrieb:

2: das kann aber ebenso ein nachteil sein. außerdem muss die factory methode sowieso als teil der klasse deklariert werden. damit ist maximal der ersteller der klasse auch der, der die factory methode schreibt und nicht jemand externer.

Nein... Nehme eine Klasse mit protected Ctor, leite davon ab und in der abgeleiteten Klasse kannst du ohne Probleme eine Factorymethode für die Basisklasse definieren.

class CantInstantiate 
{
  protected:
  CatInstantiate() {};
/*...*/
};

class YesICan : private CantInstantiate
{
public:
  CantInstantiate* InstantiateIt()
  {
    return new CantInstantiate();
  }
};

Die einzigen Möglichkeiten, um eine Klasse vor Instantiierungen zu schützen, sind ein protected Destructor und pure virtuals. Der Protected Dtor fällt bei Laufzeitpolymorphie aber aus, da man sonst nicht mehr über Basisklassenpointer delete aufrufen kann.

[besserwisser]

hmm ok. das stimmt. ein weiterer grund für abstract als keyword.

[asc]

besserwisser schrieb:

hmm ok. das stimmt. ein weiterer grund für abstract als keyword.

Wozu? Wozu ist das wirklich nötig?

class A {
    public:
        virtual ~A() {} = 0; // Und schon "abstract"
};

[Paul Manns]

besserwisser schrieb:

hmm ok. das stimmt. ein weiterer grund für abstract als keyword.

Ne^^ "= 0" tut's auch ... verarbschiede dich von der Javasyntax, wir sind hier in C++

/Edit:
Da hab ich echt ascs Beitrag glatt übersehen, sry, da steht natürlich das gleiche drin^^.

[besserwisser]

ist halt ansichtssache. ich find es nicht gut. das ist alles.

[pumuckl]

besserwisser schrieb:

hmm ok. das stimmt. ein weiterer grund für abstract als keyword.

Klar wäre es schön, das als Keyword zu haben. Gibts aber nunmal nicht, da es nicht notwendig ist. Also muss man statt dessen irgendwo ein =0 hinschreiben, und die einzige Stelle wo man das immer kann ist nunmal der Dtor, daher die Konvention abstract = pv-Dtor