abstrakte Klasse

blurry333

Hallo,

seh ich dass richtig dass abstrakte Klassen, d.h es kommt mindestens
eine pure virtual methode vor, nur für eine Vererbung gedacht sind.
Sie kann immer nur Schnittstelle sein aber nie alleine existieren ?

drakon

Jap. Genau.

fr33g

Genau, denn du kannst kein objekt einer abstrakten klasse erzeugen. Du kanndt jedoch auf eie virtuelle funktion deiner abstrakten klasse definieren, so dass die überdchriebene virtuelle methode einer geerbten klasse dann zusätzlich die funktion der abstrakten klasse aufrufen kann.

drakon

Man kann pure virtual functions sogar implementieren.

struct base
{
 virtual void foo () = 0; 
 virtual ~base (){} // never forget!
};

void base::foo ()
{
 std::cout << "hmm";
}

struct A : base
{
 void foo (){ base::foo (); }
};

int main ()
{
 A a;
 a.foo ();
}

Meiner Meinung nacht hätte man da durchaus ein neues keyword machen können, à la abstract , was im Namen mitgegeben wird.
Gründe:

Wenn ich wissen will, ob eine Klasse instanzierbar ist, will ich nicht jede Funktion checken müssen.
Es könnte ja sein, dass man bei der Wartung ausversehen alle rein virtuellen Funktionen entfernt. Und hups schon kann man sie instanzieren. -> schlecht
Es macht die Intention der Klasse klarer

Fellhuhn

Man kann seine abstraken Klassen natürlich auch einfach entsprechend benennen, dann braucht man nicht einmal nach dem Keyword schauen.

pumuckl

drakon schrieb:

Meiner Meinung nacht hätte man da durchaus ein neues keyword machen können, à la abstract , was im Namen mitgegeben wird.
Gründe:

Wenn ich wissen will, ob eine Klasse instanzierbar ist, will ich nicht jede Funktion checken müssen.

Es könnte ja sein, dass man bei der Wartung ausversehen alle rein virtuellen Funktionen entfernt. Und hups schon kann man sie instanzieren. -> schlecht

Es macht die Intention der Klasse klarer

Aus den Gründen gibts die Faustregel/best practice/Konvention, einfach bei abstrakten Klassen den Destruktor pur virtuell zu machen. Das hat zum Vorteil gegen deine Punkte:

Ich checke den Dtor und weiß bereits ob die Klasse abstrakt ist oder nicht. Da meistens Destruktoren direkt nach den Konstruktoren ganz oben deklariert werden muss man auch nicht lang suchen.
Den Dtor wird man bei der Wartung wohl kaum entfernen, da er virtuell bleiben muss, solang die Klasse als polymorphe Basis fungieren soll.
Am Destruktor kann man eigentlich immer erkennen, was Intention einer Klasse ist: - protected nonvirtuell = nichtpolymorphe Basis, pur virtuell = polymorphe Basis, sonst = andere Bestimmung

drakon

pumuckl schrieb:

Aus den Gründen gibts die Faustregel/best practice/Konvention, einfach bei abstrakten Klassen den Destruktor pur virtuell zu machen. Das hat zum Vorteil gegen deine Punkte:

Ich checke den Dtor und weiß bereits ob die Klasse abstrakt ist oder nicht. Da meistens Destruktoren direkt nach den Konstruktoren ganz oben deklariert werden muss man auch nicht lang suchen.

Den Dtor wird man bei der Wartung wohl kaum entfernen, da er virtuell bleiben muss, solang die Klasse als polymorphe Basis fungieren soll.

Am Destruktor kann man eigentlich immer erkennen, was Intention einer Klasse ist: - protected nonvirtuell = nichtpolymorphe Basis, pur virtuell = polymorphe Basis, sonst = andere Bestimmung

Ich kann jetzt nicht sehen, wo da der Vorteil gegenüber einem Keyword wäre. Das sind ja alles nur gängige Problemlösungen.
Ich sage nicht, dass man es überhaupt nicht sieht, aber der Punkt ist, dass man sich nicht drauf verlassen kann. Vielleicht hält sich jemand ja nicht an die Konventionen? - Vielleicht ist man auch daran interessiert Source Code zu parsen und dann wird das auch mit den besten Coding Absichten sehr schwer, wenn man sich auf nichts verlassen kann.

Ich finde das ja nicht so wahnsinnig schlimm, aber ich finde halt, dass man da durchaus ein Keyword hätte einführen können.

@Fellhuhn
Gleiches Problem, wie ich auch schon bei pumuckl genannt habe. Klar kann man das machen, aber der Punkt ist halt, dass es nicht einheitlich ist. Dazu kommt noch, dass ein Name ja nicht unbedingt dazu verwendet werden sollen muss, wenn man eine Eigenschaft einer Klasse festlegt.

Ich frage mich einfach wozu den Umweg über die doch seltsame Notation mit dem = 0 , wenn man das doch mit einem Keyword hätte lösen können. Ist imo auch verständlicher für Leute, die die Sprache lernen, wenn da ein abstract vor der Klasse steht, als ein = 0 nach dem Destruktor.

Fellhuhn

Da das nachträgliche Einführen von einem keyword das gleiche Problem hätte: Betrifft nur neuen Code der sich auch daran hält, wäre es auch keine wirkliche Lösung. Daher hilft nur eine gute IDE.

tntnet

drakon schrieb:

Meiner Meinung nacht hätte man da durchaus ein neues keyword machen können, à la abstract , was im Namen mitgegeben wird.

Wenn schon dann indirect . Siehe http://www.zedshaw.com/essays/indirection_is_not_abstraction.html .

drakon

Fellhuhn schrieb:

Da das nachträgliche Einführen von einem keyword das gleiche Problem hätte: Betrifft nur neuen Code der sich auch daran hält, wäre es auch keine wirkliche Lösung. Daher hilft nur eine gute IDE.

Ja, das stimmt schon.
Ich meinte ja, dass sie das damals hätten einführen können. Jetzt ist es zu spät.

Wie meinst du das mit der IDE? Welche benutzt du, dass dir angezeigt wird, ob es sich um eine abstrakte Klasse handelt? Bei VS 2008 bekomme ich das frühestens vom Compiler mitgeteilt über.

Fellhuhn

Meine IDE? SNiFF+. Der letzte Scheiss.