Beides würde für den Programmierer einer Klasse die gleichen Möglichkeiten bieten,

Ja, auf den ersten Blick schon.

Son of a Bitch schrieb:

bei eomer Komposition könnte man das assoziierte Objekt zur Laufzeit austauschen, was ein klein wenig mehr Flexibilität bringen kann.

Ja, aber wer braucht das schon?

Son of a Bitch schrieb:

Hat die Private-Vererbung auch irgend einen Vorteil, oder ist sie eigentlich komplett überflüssig?

Bei Vererbung werden alle neuen Sachen automatisch reingeerbt. Das ist eine sehr starke Bindung. Man muß schon viel Mut haben, um die einzugehen.
Allgemein kann man sagen, daß private Erblichkeit Quatsch ist. Sie wird nur angestrengt, um Schwächen der Sprache zu umgehen oder auszunutzen, zum Bleistift die Empty Member Optimization. Manche Anfänger benutzen private Erblichkeit sogar, um drei oder vier triviale einzeilige Forwarder nicht tippen zu müssen.

http://www.c-plusplus.net/forum/viewtopic-var-t-is-75672.html

...
Allgemein kann man sagen, daß private Erblichkeit Quatsch ist....

Das ist mal eine prägnante Aussage, die man sich gut merken kann.

Danke,

Simon2.

volkard schrieb:

Allgemein kann man sagen, daß private Erblichkeit Quatsch ist. Sie wird nur angestrengt, um Schwächen der Sprache zu umgehen oder auszunutzen, zum Bleistift die Empty Member Optimization.

Beispiele solcher Dinge wo private Vererbung sind machen kann:
- EBCO (wie schon genannt)
- Zugriff auf protected Member/Methoden der Basisklasse
- Überladen von virtuellen Methoden und Zugriffsgewährung an ausgesuchte Klassen (ich glaub Sutter nennts "controlled polymorphism"):

class Base
{
  virtual void foo();
};

class BigBoss;

class NotReallyDerived : private Base //offiziell bin ich kein Base,...
{
  virtual void foo();
  friend class BigBoss; //... aber BigBoss darf mich als eins benutzen!
};

Simon soo pauschal sollte man sich das nicht merken ...

Doch ... so wie "Bei Rot nicht über die Ampel".
Eine gute Richtlinie, von der man nur in begründeten Ausnahmen abweicht.

Die "Ampelregel" gilt auch nicht in jedem Einzelfall - wenn z.B. der führerlose LKW auf dich zudonnert oder Du Deine in den Wehen liegende Frau nachts um 3h auf der einsamen Landstraße ins Krankenhaus bringen willst, kann es besser sein, diese Regel zu brechen.

pumuckl schrieb:

- wenn dann den ganzen Satz:

Naja - für mich endet ein Satz beim nächsten Punkt...

Ich denke sowieso, dass es im Deutschen ein Problem mit dem Begriff "im Allgemeinen" gibt.
Manchmal ist damit gemeint: "in 90% der Fälle" und manchmal (wie oft in der Mathematik) "in jedem Zusammenhang". Ich habe o.G. im ersten Sinn verstanden und bin dir dankbar für Beispiele für die restlichen 10%.

Gruß,

Simon2.

Gruß,

Simon2.

Selbst habe ich das noch nie so gemacht, allerdings auch schon bei fremden Code gesehen.

Was haltet ihr eigentlich davon, privat abzuleiten und einzelne Funktionen mittels using öffentlich zu machen? So verhindert man, dass das Objekt als Basisklasseninstanz angesprochen wird, kann aber andere Vorteile der Vererbung nutzen.

Meistens dürfte gelten: Dazu müßte eigentlich gelten Derived IST EIN Base. Anderenfalls müßte man immer stets ununterbrpchen aufpassen, ob das geusingte noch gültig ist. Und wenn man eh IST EIN hat, kann man auch gleich öffentlich erben.

Ein ausgedachtes Beispiel: Zwei Klassen in einem GUI-Framework, Panel und Window . Panel ist eine Unterteilung des Fensters und kann selber beliebige GUI-Komponenten (auch andere Panel s) aufnehmen. Window soll das auch können, aber es muss zuoberst stehen und darf nicht als Bestandteil anderer Komponenten fungieren (darf also nicht als Panel behandelt werden). Deshalb könnte es privat von Panel erben und die gemeinsamen Funktionen öffentlich machen.

Hmm... Ganz sauber kommt mir das selber nicht vor, zumal hier gegen Aggregation nicht wirklich etwas spricht.

Ich wäre trotzdem froh um Meinungen dazu, mir fällt leider kein besseres Beispiel ein. Wenn die Beschreibung etwas ungenau war, kann ich das Beispiel gerne an einem Stück Code illustrieren.

Nämlich immer dann, wenn man eine Aggregation will, aber protected member des Objektes braucht, dann ist die private Vererbung das Einzige, was einen rettet.

Man kann damit Designschwächen anderer Bibliotheken ausbügeln

Jup. Wohl die Hauptanwendung.

Hmm. Ich würde das wahrscheinlich eher so lösen, dass ich eine Klasse Container definiere und dann kannst du da Window und Panel davon ableiten, da beide als Container fungieren und somit Container sind. (Das ist ja deine grundsätzliche Aussage oben das Window und Panel Container sind).

Panel würde aber von einer zusätzlichen (abstrakten) Basisklasse für alle GUI-Komponenten erben, sagen wir Component . Elementare Komponenten (nennen wir sie Widgets) wie Schaltflächen werden ebenfalls von dieser Klasse abgeleitet.

Wäre hier Mehrfachvererbung angebracht?

+-----------+       +-----------+
       | Container |       | Component |
       +-----------+       +-----------+
             ^                   ^
             |                   |
      +------+-------+   +-------+-------+
      |              |   |               |
+-----------+    +-----------+     +-----------+
|  Window   |    |   Panel   |     |   Widget  |
+-----------+    +-----------+     +-----------+

Potentiell gibt es sogar noch mehr, von denen du erben kannst, wenn man wirklich eine GUI Library erstellt.

Ich will nicht eine komplette GUI schreiben, eher was Kleines für SFML, vor allem für alltägliche Dinge. Erweitern kann ich es immer noch. Gerade auch deshalb habe ich mir vorgenommen, von Anfang an auf schönes Design zu achten.

Klar könnte man noch mehr machen. Ich versuche aber, allzu tiefe Klassenhierarchien zu vermeiden und die Zusammenhänge - sofern es geht - einfach zu halten. Im Gegensatz zu vielen GUIs in C++ möchte ich dem Anwender auch die Möglichkeit geben, die Komponenten selbst zu verwalten. Also vorerst nichts mit Pseudo-Garbage-Collector.

Das mit dem Container muss ich mir noch überlegen. So eine abstrakte Basisklasse macht vor allem Sinn, wenn man verschiedene abgeleitete Klassen gemeinsam ansprechen will, dafür fehlen mir gerade Anwendungsfälle. Was ich mir auch überlege, ist eine Aggregation, also dass das Fenster ein Standard-Panel besitzt (das eben das ganze Fenster ausfüllen würde). Um an diesem Änderungen vorzunehmen, könnte ich entweder Methoden wrappen, eine Referenz auf das interne Panel zurückgeben (nicht besonders sauber) oder eben private Vererbung benutzen. Letzteres scheint mir aber wie gesagt ebenfalls nicht ganz das Wahre zu sein...

Oder ich lasse den Benutzer das Panel selbst erstellen und verweise im Fenster lediglich darauf. Somit ist er flexibler. Das ist allerdings mühsam, weil man zu jedem Fenster gleich ein Panel erstellen muss, um es überhaupt benutzen zu können.

class A
{
  int foo();
  char foo(int i);
  string bar(int a, bool b, char c);
};

//böse:
class B : private A
{
public:
  using A::foo;
  using A::bar;
};

//richtig, aber aufwändig und langatmig:
class C
{
  A theA;
public:
  int foo() { return theA.foo(); }
  char foo(int i) { return theA.foo(i); }
  string bar(int a, bool b, char c) { return theA.bar(a,b,c); }
};

//schön wärs:
class D
{
  A theA;
public:
  expose theA.foo;
  expose theA.bar;
};

Im Falle öffentlicher Vererbung halte ich IST-EIN für ein brauchbares Kriterium, bei privater Vererbung aber ist es Unsinn. Wie wäre es stattdessen mit IST-IMPLEMENTIERT-MIT (oder ähnlichem)? Dann wäre auch an Nexus' Vorschlag der Übernahme von Funktionen privater Oberklassen per using nur noch wenig auszusetzen.

@pumuckl

Der Sinn von expose erschließt sich mir nicht. Was ist der Vorteil gegenüber der using-Lösung? Abgesehen halt vom IST-EIN-"Problem".

Stefan.

Ich finde es nicht nachvollziehbar, sich im Falle privater Vererbung mit der Definition "IST-EIN" aufzuhalten und dann von diesem Standpunkt aus private Vererbung zu beurteilen.
Im Falle öffentlicher Vererbung halte ich IST-EIN für ein brauchbares Kriterium, bei privater Vererbung aber ist es Unsinn. Wie wäre es stattdessen mit IST-IMPLEMENTIERT-MIT (oder ähnlichem)? Dann wäre auch an Nexus' Vorschlag der Übernahme von Funktionen privater Oberklassen per using nur noch wenig auszusetzen.

der main() kannst du sowas meinetwegen erzählen. aber glaubt die erbende klasse das denn auch? klares nein.
und wozu erben, wenn's nicht not tut? das übt doch nur unnötig druck auf die klassenhierarchie (taxonomie!) aus und führt dann zu mehrfachen erblichkeitsproblemen.

class ENTITYSYSTEM_API EntityManager : private MessageClient { ... };

class ENTITYSYSTEM_API MessageClient : boost::noncopyable {

protected:
	// Subscribes to receive messages of a specific type.
	void Subscribe(const MessageType&);

	// Unsubscribes to receive messages of a specific type.
	void Unsubscribe(const MessageType&);

	// Processes a received message. It is guaranteed that no message is received in which this
	// message client is not interested.
	virtual void ProcessMessage(const Message&) = nullptr;

};

Die Idee hier ist, dass der EntityManager am Message-System teilnehmen möchte, hierzu muss er eine virtuelle Methode overriden. Es ist aber keinesfalls gewünscht, dass jemand von außen den EntityManager für irgendwas subscriben kann, sondern der EntityManager weiß selber genau, was für Messages er braucht.

Daher fällt öffentliche Vererbung aus. Komposition wäre umständlich, ich müsste erst von MessageClient ableiten und eine Instanz dieser konkreten Klasse als member aufnehmen. Daher finde ich das hier eine brauchbare Lösung (andere Meinungen mit Begründung sind willkommen).

Trotzdem zieht man im Allgemeinen Komposition natürlich vor. Schlauerweise nimmt man immer die schwächste Verbindung, die noch sinnvoll ist, also Aggregation, Komposition, Vererbung und nur zuletzt friend.

virtual void ProcessMessage(const Message&) = nullptr;

Da ist auch nullptr erlaubt?

Ich hab letztens private Vererbung hierfür eingesetzt:...

Alternativ könnte man überlegen, nicht nur Empfängerobjekte zu registrieren, die je nach Nachricht eine bestimmte virtuelle Funktion anbieten müssen, sondern beliebige Objekte/Methodenzeiger-Paare registrieren zu können.

Ich finde es nicht nachvollziehbar, sich im Falle privater Vererbung mit der Definition "IST-EIN" aufzuhalten und dann von diesem Standpunkt aus private Vererbung zu beurteilen.

Im Falle öffentlicher Vererbung halte ich IST-EIN für ein brauchbares Kriterium, bei privater Vererbung aber ist es Unsinn. Wie wäre es stattdessen mit IST-IMPLEMENTIERT-MIT (oder ähnlichem)?

Dann schon "IST-IMPLEMENTIERT-MIT-UND-FÜR-SICH-SELBST-UND-IM-KREISE-DER-FREUNDE-IST-EIN" - für sich selbst und für alle friends gilt nunmal die Ist-Ein-Beziehung. Und die wegzudiskutieren hilft auch nicht dagegen dass es semantisch eben etwas anderes ist als Aggregation.

DStefan schrieb:

@pumuckl

Der Sinn von expose erschließt sich mir nicht. Was ist der Vorteil gegenüber der using-Lösung? Abgesehen halt vom IST-EIN-"Problem".

Eben. Abgesehn von der Typsicherheit kann man auch Makros an Stelle vieler Templates benutzen. Man kann für viele Schwächen der Sprache Workarounds finden, die super funktionieren auch wenn sie eigentlich was anderes bedeuten.

btw:

class E
{
  A someA;
  A anotherA;
public:
  expose someA.foo;
  expose anotherA.bar;
};

nicht machbar mit Vererbung

Optimizer schrieb:

virtual void ProcessMessage(const Message&) = nullptr;

Da ist auch nullptr erlaubt?

Ich hoffe es. Im Moment ist es nur ein #define.