🚀 go-pugleaf

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