🚀 go-pugleaf

pauman@apars1.apa.co.at (Mario Paumann) wrote:
>Hallo!
>
>Kann mir einer sagen warum das nicht
>moeglich sein sollte ?
>
>class mein {
>    ...
>  public:
>    ...
>    virtual ~mein()=0;
>    ...
>};
>
>Danke, mario

Vielleicht steht's so in der Spezifikation?

Wo genau liegt denn das Problem? Beim compilieren der
Klasse, dadurch, dass keine abgeleitete Klasse existiert,
die den Destruktor definiert (dann hast Du eine pure
virtual class, die kann nicht aufgerufen werden).




--
Markus Becker	            http://www.zess.uni-siegen.de/private/becker/
Zentrum fuer Sensorsysteme (ZESS)
http://www.zess.uni-siegen.de/private/becker/win95

Mario Paumann wrote:
> 
> Hallo!
> 
> Kann mir einer sagen warum das nicht
> moeglich sein sollte ?
> 
> class mein {
>     ...
>   public:
>     ...
>     virtual ~mein()=0;
>     ...
> };
> 
> Danke, mario

Alles was als =0 declariert wird, muss in der erbenden Klasse
ueberschrieben werden. Das geht bei Con/Destructoren natuerlich
nicht. Denn die werden ja nicht ueberschrieben, sondern als
Stack aufgerufen. Also, wenn ich noch

class mein2 : mein
und
class mein3 : mein2
habe, 

werden beim erschaffen von einem mein3 Object die 
Constructoren von mein, mein2 und mein3 hintereinander aufgerufen.

Beim ende der Lebenszeit werden die destructoren von mein3, mein2
und mein aufgerufen. Ohne wenn und aber. In diesem Konzept
ist kein Platz fuer abstracte destructoren.

Joern

PS: Was soll das eingentlich?

Mario Paumann wrote:
> 
> Hallo!
> 
> Kann mir einer sagen warum das nicht
> moeglich sein sollte ?
> 
> class mein {
>     ...
>   public:
>     ...
>     virtual ~mein()=0;
>     ...
> };
> 

Wird eine Instanz einer Klasse entfernt, werden u.a. die Destruktoren
aller Basisklassen aufgerufen. Das obige Bsp. allein duerfte keine
Probleme bereiten, im Gegensatz zu:

		struct mein { virtual ~mein()=0; };
		struct dein : mein {};
		int main() { dein d; return 0; }

Das Entfernen von 'd' kann hier nicht funktionieren, da der Destruktur
in 'mein' als pure-virtual deklariert ist _und_ keine Implementierung
vorliegt. Aendert man das Programm zu:

		struct mein { virtual ~mein()=0; }
		mein :: ~mein() {}
		struct dein : mein {};
		int main() { dein d; return 0; }

funktioniert es, da nun eine Implementierung des Destruktors vorliegt.

	Enno

Mario Paumann wrote:

> Kann mir einer sagen warum das nicht
> moeglich sein sollte ?
> 
> class mein {
>     ...
>   public:
>     ...
>     virtual ~mein()=0;
>     ...
> };

Und: wozu soll das denn gut sein?
-- 
*	Greetinx,
	Watson (sayegh@fokus.gmd.de)
	more personal details at:
	http://www.fokus.gmd.de/ovma/employees/sayegh/entry.html

Mario Paumann (pauman@apars1.apa.co.at) wrote:
>  Hallo!

>  Kann mir einer sagen warum das nicht
>  moeglich sein sollte ?

>  class mein {
>      ...
>    public:
>      ...
>      virtual ~mein()=0;
>      ...
>  };

>  Danke, mario

Es ist durchaus moeglich. Allerdings muss trotzdem noch die Funktion
'mein::~mein()' definiert werden, z.B.

  mein::~mein()  {  }

Grund: Auch wenn der Destruktor einer von 'mein' abgeleiteten Klasse aufgerufen
wird, ruft dieser anschliessend den Destruktor von 'mein' auf. 'mein::~mein()' 
muss also in jedem Fall definiert sein. Virtuelle Destruktoren unterscheiden
sich insofern von allen anderen virtuellen Funktionen.

Gruss
	Bernd 

--
+----------------------------------+
|          Bernd Eggink            |
|    Rechenzentrum Uni Hamburg     |
| admin@rzaix13.rrz.uni-hamburg.de |
+----------------------------------+

In article <4cu4it$675@news.Austria.EU.net> pauman@apars1.apa.co.at (Mario Paumann) writes:
	...

      > aller Basisklassen aufgerufen. Das obige Bsp. allein duerfte keine
      > Probleme bereiten, im Gegensatz zu:
      Das hab ich auch geglaubt, aber mein HPUX C++ Compiler
      gibt mir dieses Warning
      - CC: "TripService.h", line 38: warning: please provide an out-of-line
      - definition:  mein::~mein() {}; which is needed by
      - derived classes (245)

Mit Problem meinte ich eine Fehlermeldung - keine Warnungen. Warnungen sind
Compiler-abhaengig, z.B. koennte ein Compiler 'unsauber eingerueckte'
Programme mit Warnungen versehen.
Allerdings scheinen sich die Entwickler des HPUX Compilers wirkliche Muehe
gegeben zu haben auch aussergewoehnlichere Faelle zu beruecksichtigen.

      Pure-virtual Functions sind ja dazu entwickelt worden, dass
      man keinen Funktionsrumpf schreiben muss der eigenltich nichts
      enthaelt, deshalb hab ich immer geglaubt dasz man ENTWEDER =0 ohne
      Funktionsrumpf ODER Funktionsrumpf ohne =0 angibt.

Pure-virtual functions (pvf) dienen neben Modellierungs-Aspekten dazu das
Erzeugen von Instanzen einer bestimmten Klasse zu unterbinden. Wenn die Klasse
eine pvf hat, kann man keine Instanzen von ihr erzeugen.
BTW man kann generell, also nicht nur fuer Destruktoren, Implementierungen
fuer pvf anbieten.

      Aber es geht anscheinend auch beides. D.h. man kann (und
      wie die Fehlermeldung von oben auch zeigt VERLANGT mein
      CC-Compiler das sogar) einen Funktionsrumpf für eine
      pure-virtual Function definieren.
      Ausserdem hab ich angenommen, daß pure virtuelle Destruktoren
      nichts ausmachen, da eine Klasse ja nicht unbedingt einen
      Destruktor braucht. Aber um (wie oben schon angerissen)
      eine Objekt ueber einen Pointer vom Typ der (abstrakten!)
      Basisklasse zu deleten, muss diese Funktion auch in der
      Basisklasse definiert werden (und zwar als virual).
      So. Fertiggelabbert :)

   Spezifikation hin oder her, theoretisch muesste sowas
   ohne Probleme moeglich sein odrrr?

   Schreibt mir doch bitte mal die Reaktionen von eueren Compilern
   zu diesem Codestueck (dieses sollte direkt compilierbar sein) :

   #include <iostream.h>

   struct mein { virtual ~mein()=0; };

   struct dein:mein { virtual ~dein(); };
   dein::~dein() { cout << "~dein" << endl; }

   main()
   { dein d;
     return 0;
   }                                         

Nein, das Bsp. Programm hat ebenfalls das Problem, dass der Destruktor von
'dein' den als pure-virtual deklarierten (+ nicht def.) Destruktor von 'mein'
aufrufen muesste. Das Programm sollte also nicht uebersetzbar sein.
g++ beschwert sich z.B. beim Linken, dass 'mein :: ~mein()' nicht vorhanden
ist. Mir ist kein portabler Weg bekannt, wie man den Aufruf der Basisklassen-
destruktoren unterdruecken koennte (mir war auch noch nie danach ... ;-).
Insofern muss der Destruktor von 'mein' definiert sein, falls von irgendwel-
chen Unterklassen von 'mein' Instanzen erzeugt werden sollen.

        Enno

Ok. Ich versuchs nochmal genauer zu erklaeren :

1. Es ist klar das diese Klasse (mein) eine abstrakte
   Klasse ist dies ist gewollt und hier lag auch nicht
   der Fehler (z.Hd. Markus Becker)
2. Bei Klassen die über Pointer der abstrakten Basisklasse
   deleted werden, sollte nicht der Destruktor der Basis-
   klasse sondern der von der abgeleiteten Klasse (hierzu
   sind ja die virtuellen Destruktoren eingefuert worden)
   aufgerufen werden (z.Hd. Joern Sierwald)
3. z.Hd. Enno Sandner : Du hast es erfasst :
   > aller Basisklassen aufgerufen. Das obige Bsp. allein duerfte keine
   > Probleme bereiten, im Gegensatz zu:
   Das hab ich auch geglaubt, aber mein HPUX C++ Compiler
   gibt mir dieses Warning
   - CC: "TripService.h", line 38: warning: please provide an out-of-line
   - definition:  mein::~mein() {}; which is needed by
   - derived classes (245)
   Pure-virtual Functions sind ja dazu entwickelt worden, dass
   man keinen Funktionsrumpf schreiben muss der eigenltich nichts
   enthaelt, deshalb hab ich immer geglaubt dasz man ENTWEDER =0 ohne
   Funktionsrumpf ODER Funktionsrumpf ohne =0 angibt.
   Aber es geht anscheinend auch beides. D.h. man kann (und
   wie die Fehlermeldung von oben auch zeigt VERLANGT mein
   CC-Compiler das sogar) einen Funktionsrumpf für eine
   pure-virtual Function definieren.
   Ausserdem hab ich angenommen, daß pure virtuelle Destruktoren
   nichts ausmachen, da eine Klasse ja nicht unbedingt einen
   Destruktor braucht. Aber um (wie oben schon angerissen)
   eine Objekt ueber einen Pointer vom Typ der (abstrakten!)
   Basisklasse zu deleten, muss diese Funktion auch in der
   Basisklasse definiert werden (und zwar als virual).
   So. Fertiggelabbert :)

Spezifikation hin oder her, theoretisch muesste sowas
ohne Probleme moeglich sein odrrr?

Schreibt mir doch bitte mal die Reaktionen von eueren Compilern
zu diesem Codestueck (dieses sollte direkt compilierbar sein) :

#include <iostream.h>

struct mein { virtual ~mein()=0; };

struct dein:mein { virtual ~dein(); };
dein::~dein() { cout << "~dein" << endl; }

main()
{ dein d;
  return 0;
}                                         



Danke, mario

Joern Sierwald wrote:
> 
> Mario Paumann wrote:
> >
> > Hallo!
> >
> > Kann mir einer sagen warum das nicht
> > moeglich sein sollte ?
> >
> > class mein {
> >     ...
> >   public:
> >     ...
> >     virtual ~mein()=0;
> >     ...
> > };
 
Ich habe es gerade mal mit meinem Lieblingscompiler (*) uebersetzt. 
Er schluckt es. Dann noch ne abgeleitete Klasse dazu und ein
main() program -> link error: ~mein() not found.
Also mein::~mein() {}; dazu -> laeuft.

Sehr seltsam und ueberhaupt nicht das, was ich erwartet haette.
Aber man lernt ja dazu...


Joern


(*) TopSpeed C++ for DOS 3.01

Mario Paumann <pauman@apars1.apa.co.at> schrieb zu
Re: virtueller Destruktor mit =0 ?
in Artikel <4cu4it$675@news.Austria.EU.net> vom 09.01.96:

> Schreibt mir doch bitte mal die Reaktionen von eueren Compilern
> zu diesem Codestueck (dieses sollte direkt compilierbar sein) :
>
> #include <iostream.h>
>
> struct mein { virtual ~mein()=0; };
>
> struct dein:mein { virtual ~dein(); };
> dein::~dein() { cout << "~dein" << endl; }
>
> main()
> { dein d;
>   return 0;
> }

Microsoft Visual C++ V1.0:

---schnipp-------------------------------------------------------- 
Compiling...
c:\tmp\test.cpp
Linking...

TEST.OBJ(c:\tmp\test.cpp) : error L2029: 'public: virtual
   __far __pascal mein::~mein(void)__near' : unresolved external

 LINK returned error code 2.
Creating browser database...
TEST.EXE - 1 error(s), 0 warning(s)
---schnapp--------------------------------------------------------

Turbo C++ V1.0

---schnipp--------------------------------------------------------
===Message===
 Compiling C:\TMP\EST.CPP:
 Linking C:\SPRACHEN\TC\BIN\EST.EXE:
 Linker Error: Undefined symbol mein::~mein() in module \TMP\EST.CPP
---schnapp--------------------------------------------------------

Ziemlich klar: dem Compiler ist's egal, aber der Linker findet den  
Funktionsrumpf von mein::~mein (der ja nicht existiert) nicht,  
wenn ihn der Destruktor von dein::~dein aufrufen will...

> Danke, mario
Bitte, gern geschehen.

Claus

------------------------------------------------------------------------
Claus Andre Faerber - claus@faerber.muc.de - http://www.muc.de/~cfaerber
                    >>> Windows - best before 95 <<<
------------------------------------------------------------------------

In article <4cu4it$675@news.austria.eu.net>,
Mario Paumann <pauman@apars1.apa.co.at> wrote:
>Ok. Ich versuchs nochmal genauer zu erklaeren :
>
>...
>2. Bei Klassen die über Pointer der abstrakten Basisklasse
>   deleted werden, sollte nicht der Destruktor der Basis-
>   klasse sondern der von der abgeleiteten Klasse (hierzu
>   sind ja die virtuellen Destruktoren eingefuert worden)
>   aufgerufen werden (z.Hd. Joern Sierwald)

OHA, vielleicht liegt hier das Missverstaendnis !!!
Bei Zerstoeren werden ALLE Destruktoren einer Hierarchie
verkettet bottom-up aufgerufen.
Insofern macht es absolut keinen Sinn, die Implementierung einer
abgeleiteten Klasse zu ueberlassen.
Deshalb ist immer einfach nur ein leerer virtueller
Destruktor zu implementieren.

Mich irritiert allerdings voellig, dass in einigen Antworten
angedeutet wird, eine irgendwie geartete Definition mit "=0"
koennte moeglich sein.
Ich halte das fuer falsch, habe es aber nicht anhand vom Standard
nachgeprueft.

>Spezifikation hin oder her, theoretisch muesste sowas
>ohne Probleme moeglich sein odrrr?
Wenn jemand sagt, dass es theoretisch moeglich sei, ist es
praktisch unmoeglich.

Tschau
-- 
Nico                             address: BREDEX GmbH, Nicolai Josuttis
email:   nico@bredex.de                   Fallersleber-Tor-Wall 23
phone:   +49 531 24330-0                  D-38100 Braunschweig
fax:     +49 531 24330-99                 Germany

Nico Josuttis wrote:
> 
> ...
> 
> Mich irritiert allerdings voellig, dass in einigen Antworten
> angedeutet wird, eine irgendwie geartete Definition mit "=0"
> koennte moeglich sein.
> Ich halte das fuer falsch, habe es aber nicht anhand vom Standard
> nachgeprueft.
> 

Fuer den pure-virtual Destruktor steht das unter 12.4 [class.dtor]
des DWP:

6 ... A destructor can be  declared  virtual (_class.virtual_) or
  pure virtual (_class.abstract_); if any objects of that class or
  any derived class are created  in  the  program, the destructor
  shall be defined. ...

Fuer Member-Functions liefert 10.3 [class.virtual] die Rechtfertigung:

8 A virtual function declared in a class shall be defined, or declared
  pure (_class.abstract_) in that class, or both; but no diagnostic is
  required (_basic.def.odr_).

Ueber den Sinn eines solchen Features laesst sich sicherlich streiten.
Man koennte es z.B. dazu verwenden, um Teilen der von Funktionen in
einem Interface ein 'Default-Verhalten' zuzuordnen:

lib.H:
struct AnyItf {
  virtual void some_func()=0;
};

inline void AnyItf :: some_func() { /* Default-Verhalten */ }

client.C:
#include "lib.H"

struct SomeImpl : AnyItf {
  void some_func() {
    AnyItf :: some_func();
    /* Zusaetzliche Funktionalitaet */
  }
};

...
Dabei sei 'lib.H' das Headerfile einer Bibliothek und 'client.C' ein 
Nutzer dieser Bibliothek. Der springende Punkt dabei ist, dass die
Definition des Default-Verhaltens, ins Headerfile gehoert (zumindest
deren Deklaration). Ansonsten koennte der Benutzer nicht ahnen, dass
eine Implementierung fuer 'some_func' angeboten wird.
(Eine alternative Lsg. zum obigen Szenario waere es, 'some_func' nicht als
pure zu deklarieren und irgendeine Dummy (pure-virtual) Funktion einzufuehren,
die dann garantiert, dass die Klasse abstrakt ist.)
Unter diesen Rahmenbedingungen laesst sich dieses Feature vielleicht
vernuenftig einsetzen.

	Enno

Mario Paumann (pauman@apars1.apa.co.at) wrote:
: Ok. Ich versuchs nochmal genauer zu erklaeren :

:    Pure-virtual Functions sind ja dazu entwickelt worden, dass
:    man keinen Funktionsrumpf schreiben muss der eigenltich nichts
:    enthaelt, deshalb hab ich immer geglaubt dasz man ENTWEDER =0 ohne
:    Funktionsrumpf ODER Funktionsrumpf ohne =0 angibt.
:    Aber es geht anscheinend auch beides. D.h. man kann (und
:    wie die Fehlermeldung von oben auch zeigt VERLANGT mein
:    CC-Compiler das sogar) einen Funktionsrumpf für eine
:    pure-virtual Function definieren.

Das Problem ist allerdings, dasz Destruktoren IMMER vorhanden sein mueszen. 
Immer heiszt, deklarierst und definierst Du keinen (was -- zumindest bei 
BC++ -- durchaus moeglich ist), dann fuegt der Compiler einen ,,versteckten`` 
hinzu. 
Dies ist fuer C++ einfach hinzunehmen. Gruende magst Du vielleicht in 
Stroustrups ,,Design and Evolution of C++`` finden. 

                                                       Schobi

--
"Zehn Deutsche sind natuerlich duemmer als fuenf Deutsche." H.M.