"pure virtual destructor"

[RHBaum]

Basisklassen bieten ein Interface das allen konkreten Klassen gemeinsam ist, konkrete Klassen sind dazu da, Objekte davon zu schaffen.

Ja richtig ...
Aber genau dann sollte man das auch so trennen, und ich wuerd die ganze hirarchie als interface pure abstract machen
Dann sind die interfaces sauber und jede weitere ableitung in der hirarchie bringt nur weitere pure virtuale methoden mit sich ...

Was intern dann benutzt um ne implementation deiner interfaces zur verfuegung zu stellen, ist dann ne ganz andere schiene ....

Man sollte halt auch interface von Impl trennen, das halt bei themen mit standardfunktionalitaet nimmer der fall ...

Basisklassen bieten ein Interface das allen konkreten Klassen gemeinsam ist, konkrete Klassen sind dazu da, Objekte davon zu schaffen

Die vorraussetzung fuer die technik selber ist aber schon die verletzung an sich ... in dem du klassen hasst, die halb interface, halb Impl sind.
Also einfach dem ding nen eigenes erweitertes interface(pure abstrakt) fuer die virtuellen funktionen um die es die Schnittstelle erweitert, und schon hasst wieder ne trennung .. und niemand kann jemanden vorwuerfe wegens design machen, weil wer deine "Halbe Impl die aber vollstandig funktioniert" direkt instanziiert.

Ciao ...

[pumuckl]

Hm da hab ich mich wohl etwas Mißverständlich ausgedrückt. Mit dem Interface wraen in dem Fall nicht nur Funktionsdeklarationen gemeint, also keine Interface-Klasse wie man sie aus Java kennt, sondern eben alles was eine Basisklasse in einer polymorphen Klassenhierarchie ausmacht.
Die Eigenschaft, polymorphe Basisklasse zu sein sowie die Eigenschaft, konkrete Klasse zu sein sind eben nach Auffassung vieler Leute voneinander zu trennen und daher Basisklassen in polymorphen Hierarchien grundsätzlich abstrakt zu halten.

[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