Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Ich habe mal eine Frage,schreibe nämlich bald eine Klausur: Was ist der Unterschied zwischen einer virtuellen Methode und ein er rein virtuellen Methode. Bei der einen steht dann =0. Aber was ist sonst der wesentliche Unterschied???
Nun!
Eine virtuelle Methode muss in der Basisklasse definiert werden. Es kann aber von der Basisklasse noch eine Instanz erzeugt werden. Bei einer rein virtuellen Klasse muss die Methode in einer abgeleiteten Klasse definiert werden. Es kann auch keine Instanz mehr angelegt werden. Rein virtuelle Methoden benutzt man (vorallem) für Interfaces, d.h. abgeleitete Klassen haben gefälligst die Methoden des Interfaces zu definieren.
Den Begriff "rein virtuelle Methode" habe ich ja noch nie gehört. Bei mir im Studium haben wir gelernt, dass eine Methode, die nicht implementiert wurde (also ein =0 da stehen hat), eine abstrakte Methode wäre.
Abstrakt, rein virtuell, pure virtual, das findet man alles und der Jargon unterscheidet sich von Sprache zu Sprache ein wenig. In C++ ist in der Tat abstrakt aber weniger gebräuchlich.
Rein virtuelle Methoden haben keine Implementierung. Sie können zwar im Code aufgerufen werden, der Aufruf wird aber immer an die überschriebene Methode der ("am meisten" (engl. most derived)) abgeleiteten Klasse weitergeleitet. Von Klassen mit rein virtuellen Methoden können somit keine Objekte erzeugt werden. Aus Codesicht macht man damit deutlich, dass sie mit einem sinnvollen Verhalten überschrieben werden müssen. Rein virtuelle Methoden sollte man übrigens immer private Sichtbarkeit geben, da sie von Unterklassen eh nicht aufgerufen werden können/dürfen.
Virtuelle Methoden haben dagegen meist eine sinnvolle Default-Implementierung und hauchen der Klasse ein Standardverhalten ein, was durch abgeleitete Klassen aber auch noch überschrieben werden kann. Gelegentlich kommt es vor, dass virtuelle Methoden für ein sinnvolles Verhalten auch noch die entsprechende Methode des Vorfahren aufrufen müssen. Das ist allerdings eher selten notwendig und deutet auf Design-Probleme hin. Wenn sie dagegen nicht von Unterklassen aufgerufen werden müssen, oder sogar nicht aufgerufen werden dürfen, sollte man sie auch immer private machen.
Rein virtuelle Methoden haben keine Implementierung. Sie können zwar im Code aufgerufen werden, der Aufruf wird aber immer an die überschriebene Methode der ("am meisten" (engl. most derived)) abgeleiteten Klasse weitergeleitet. [...] Rein virtuelle Methoden sollte man übrigens immer private Sichtbarkeit geben, da sie von Unterklassen eh nicht aufgerufen werden können/dürfen.
Also zumindest in C++ können rein virtuelle Methoden auch eine Implementierung haben (man denke nur an einen rein virtuellen Destruktor), und diese kann auch von Unterklassen aufgerufen werden. Ob das (mit Ausnahme des Destruktors) für ein schönes Design spricht ist natürlich fraglich.
Ja da hast du schon recht. Ich wollte diese Schweinereien mal unter den Tisch fallen lassen. Für einen rein virtuellen Destruktor habe ich allerdings auch noch kein überzeugendes Argument gefunden. Warum sollte jemand den Destruktor überschreiben müssen? Doch nur, um der Basisklasse sinnvolles Verhalten einzuhauchen beim Zerstören, was äußerst gruselig wäre und ein noch wesentlich fragwürdigeres Design als das Aufrufen einer geerbten virtuellen Methode.
In diesem Falle kann man genauso gut die Konstruktoren protected machen, was imho eine wesentlich klarere Schnittstelle ist.
Der rein virtuelle Destruktor macht Sinn wenn deine Klasse unbedingt abstrakt sein soll, aber keine der anderen Methoden rein virtuell ist. Protected Konstruktor erreicht ja mehr oder weniger das gleiche, aber er macht die Klasse eben nicht abstrakt. Für mehr Informationen über die "Schweinereien" mit rein virtuellen Methoden siehe zum Beispiel http://www.gotw.ca/gotw/031.htm.
Der rein virtuelle Destruktor muss übriges nicht "von Hand" überschrieben werden, dafür reicht auch der automatisch generierte Standard-Destruktor.
Japps, ich kenn den Artikel. Aber was kann man sich von einer abstrakten Klasse "kaufen"? Wenn du nicht willst, dass sie erzeugt werden kann, erreicht man das mit protected Konstruktoren.
Während du dich als Entwickler einer abgeleiteten Klassen fragen kannst "warum zum Geier ist dieser Destruktor pure virtual" (und dir die Definition des Destruktors anschauen musst - soforn diese überhaupt einsehbar ist), ist der Sinn von deaktivierten Konstruktoren absolut klar.
Natürlich kann man die Konstruktion auch mit einem pure virtual Destruktor verhindern, allerdings ist das erstmal eine recht implizite Aussage, dass man nicht "mehr" damit erreichen will. Deaktivierte Konstruktoren machen das Ganze explizit. Bei einer Klasse, die zur öffentlichen Ableitung gedacht ist, sollte man sowieso den Copy-Konstruktor protected/private machen. Da kann man den Default-Konstruktor auch gleich dazu packen, wenn man schonmal dabei ist.
Ganz nebenbei werden die Konstruktoren natürlich auch von ihren Default-Kollegen beim Ableiten überschrieben falls das möglich ist und wenn man sie nicht selbst implementiert.
Naja, ich persönlich denke bei einer abstrakten Klasse (und auch bei einem rein virtuellen Destruktor) sofort an Klassenhierarchien und Vererbung, während ich bei deaktiviertem Konstruktor erstmal an so Sachen wie Singletons denke. Letztlich funktioniert natürlich beides, ist wohl eher eine subjektive Entscheidung.
Für einen rein virtuellen Destruktor habe ich allerdings auch noch kein überzeugendes Argument gefunden. Warum sollte jemand den Destruktor überschreiben müssen? Doch nur, um der Basisklasse sinnvolles Verhalten einzuhauchen beim Zerstören, was äußerst gruselig wäre und ein noch wesentlich fragwürdigeres Design als das Aufrufen einer geerbten virtuellen Methode.
