(dringend)abstrakte klassen frage

[Slade100]

hey leute,
habe morgen früh eine mündliche prüfung in c++ und eigentlich dachte ich vom vorwissen ausm internet das eine klasse abstakt ist sobald es eine pure virtuelle methode gibt, nun hab ich eben das skript vom prof durchgeschaut und dort steht folgendes:
1.2.1 Abstrakte Klassen
- weisen mindestens eine abstrakte Methode auf
- können nicht instanziert werden
- abstrakte Methoden haben nur die Schnittstellendefinition
(Signatur, Prototyp), keinen Code!

Beispiel der Verwendung für abstrakte Klassen:

class AllGO{
int linetype; int linewidth;
public: void draw();
};
class Dreieck:AllGO{
point p1, p2, p3;
public: void draw(){…} …
};
class Viereck:AllGO{
point p1, p2, p3, p4;
public: void draw(){…} …
};

wasn nun? liegt der prof falsch oder wieso steht es im internet überall anders?
ausserdem kann man für pure virtuelle funktionen ja auch einen code haben(zwar nicht beim prototyp aber ausserhalb der klasse dann)

meine 2. frage ist, wenn man eine abstrakte klasse hat mit dynamischen attributen, wo sollte delete benutzt werden um den speicher der attribute frei zugeben? im destrukter der abstrakten klasse oder die klasse, die von ihr abgeleitet wurde?

[Shadow992]

Originally Posted by Slade100

hey leute,
habe morgen früh eine mündliche prüfung in c++ und eigentlich dachte ich vom vorwissen ausm internet das eine klasse abstakt ist sobald es eine pure virtuelle methode gibt, nun hab ich eben das skript vom prof durchgeschaut und dort steht folgendes:
1.2.1 Abstrakte Klassen
- weisen mindestens eine abstrakte Methode auf
- können nicht instanziert werden
- abstrakte Methoden haben nur die Schnittstellendefinition
(Signatur, Prototyp), keinen Code!

Beispiel der Verwendung für abstrakte Klassen:

class AllGO{
int linetype; int linewidth;
public: void draw();
};
class Dreieck:AllGO{
point p1, p2, p3;
public: void draw(){…} …
};
class Viereck:AllGO{
point p1, p2, p3, p4;
public: void draw(){…} …
};

wasn nun? liegt der prof falsch oder wieso steht es im internet überall anders?
ausserdem kann man für pure virtuelle funktionen ja auch einen code haben(zwar nicht beim prototyp aber ausserhalb der klasse dann)

meine 2. frage ist, wenn man eine abstrakte klasse hat mit dynamischen attributen, wo sollte delete benutzt werden um den speicher der attribute frei zugeben? im destrukter der abstrakten klasse oder die klasse, die von ihr abgeleitet wurde?

@2

Kaskadierende Konstruktoren
Bevor der Konstruktor einer abgeleiteten Klasse ausgeführt wird, wird immer der Konstruktor der Basisklasse gestartet. Umgekehrt ist es beim Destruktor. Hier wird der Destruktor der Basisklasse zuletzt aufgerufen. Dieses Verhalten ist logisch, da abgeleitete Klassen auf den Eigenschaften der Basisklassen aufbauen. Entsprechend muss das Basisobjekt konstruiert sein, bevor der Konstruktor der abgeleiteten Klasse aufgerufen wird. Entsprechendes gilt beim Destruktor. Der Destruktor der Basisklasse muss zuletzt aufgerufen werden, damit das Basisobjekt nicht bereits zerstört ist, wenn die abgeleitete Klasse noch versucht, die Erweiterungen freizugeben.

Quelle:

Das heißt du kannst/solltest die "dynamische" Attribute (klingt für mich etwas komisch, besser "dynamisch angeforderte Attribute" oder noch besser "auf dem Heap liegende Daten") so weit oben wie möglich löschen lassen bzw. auf derselben Ebene wie sie angefordert werden.

@1
Ich glaube der Prof hat veraltetes Wissen.
Wenn ich mich richtig erinnere war es in C++98 nicht möglich virtual Methoden zu implementieren (aber wie gesagt sicher bin ich mir nicht, kurzes googlen hat mir auch nicht wirklich gezeigt wie es in C++98 war).

Sollte es in C++98 doch möglich gewesen sein, wird er wohl an Java gedacht haben. Wobei auch dort ist es nicht richtig, weil seine Aussage nur für Interfaces gilt.

Alles in allem:
Irgendetwas passt an seiner Aussage nicht, der Sinn von abstrakten Klassen ist es ja unter anderem, dass man Methoden in der entsprechenden Superklasse implementieren kann und diese dann vererben kann ohne große Probleme.
Er scheint also etwas verwechselt zu haben.