ich hänge gerade an einer Aufgabe und deren Lösung fest: Es soll ein Stack-Template basierend auf einer allgemeinen Klasse Liste geschrieben werden.
Von der Oberklasse poste ich mal nur die Schnittstellen. Ich denke, das reicht.

template<class T> 
class Liste {
    public:
      Liste();
      Liste(const Liste&);
      ~Liste();
      Liste& operator=(const Liste&);

      bool empty() const { return anzahl == 0;}
      int size()   const { return anzahl;}

      // am Anfang bzw. Ende einfügen
      void push_front(const T&);
      void push_back(const T&);

      // am Anfang bzw. Ende löschen
      void pop_front();
      void pop_back();

      // am Anfang bzw. Ende lesen
      T&       front();
      const T& front() const;
      T&       back();
      const T& back() const;

      // anwenden der Funktion {\tt f()} auf alle Elemente
      void anwenden(void(*f)(const T&)) const;

    private:
      struct Listenelement { 
         friend class Liste<T>;
         T daten;
         Listenelement *naechstes, *vorgaenger;
         Listenelement(const T& dat)
         : daten(dat), naechstes(NULL), vorgaenger(NULL) {}
        private:
         // private, um versehentliche Benutzung zu verhindern
         Listenelement(const Listenelement&);
         void operator=(const Listenelement&);
      };

      Listenelement *ende, *anfang;
      size_t anzahl;
};

Wie man sehen kann, benutzt die Klasse "Liste" eine Struktur "Listenelement" zur internen Speicherung.
Nun das Template der Stack-Klasse:

#ifndef STACK_T
#define STACK_T
#include "liste.t"

template<class T>
class Stack : private Liste<T> {
	public:
		using Liste<T>::empty;
		using Liste<T>::size;

		void push(const T&);
		void pop(void);
		const T& top(void) const;
		T& top(void);
};

void Stack<T>::push(const T& x) {
	Liste<T>::push_front(x);
}

void Stack<T>::pop() {
	Liste<T>::pop_front();
}

const T& Stack<T>::top() const {
	Liste<T>::front();
}

T& Stack<T>::top() const {
	Liste<T>::front();
}

#endif

Das war meine Lösung. Wie ihr sehen könnt, produziert sie leider einige Fehler zu viel, um durch den Compiler zu kommen.

Die abgedruckte Lösung war diese:

#ifndef STACK_T
#define STACK_T
#include "liste.t"

template<class T>
class Stack {
    public:
      bool empty() const     { return liste.empty();}
      int size()   const     { return liste.size();}
      // am Anfang einfügen und entnehmen
      void push(const T& x)  { liste.push_front(x);}
      void pop()             { liste.pop_front();}
      // am Anfang lesen
      T&       top()         { return liste.front();}
      const T& top() const   { return liste.front();}
    private:
      Liste<T> liste;
};
#endif

So, jetzt zum Kern des Problems...
Im Kapitel zur privaten Vererbung steht, dass Delegation (wie in der Musterlösung) und Implementationsvererbung/private Vererbung (meine Variante) beides Möglichkeiten zur Wiederverwendung von Code seien. Delegation würde allerdings bevorzugt. Da jedoch schon ein weiteres Beispiel einer delegierenden Klasse angegeben war, wollte ich die private Vererbung mal ausprobieren. Leider ohne Erfolg...

Ist das Ganze weitgehend äquivalent und hab ich nur 'nen Fehler gemacht oder lieg ich hier total daneben?

Danke für eure Antworten.

~moagnus

Nur damit ich das richtig verstehe: Durch meine private-Vererbung werden erstmal alle public und protected Methoden und Attribute zu private Attributen der Unterklasse. Mit "public: using Liste<T>::empty;" kann ich dann 'ne Oberklassenmethode wieder public für die abgeleitete Klasse nutzbar machen. Soweit richtig?
Wenn ich jetzt aber keinen Krampf mach und keine ungültigen Methoden der Basisklasse für den Stack übernehme, ist private Vererbung doch auch ok, oder? Werde in Zukunft soweit möglich Delegationen benutzen, wie's mir die Seite hier empfiehlt. (http://www.parashift.com/c++-faq-lite/private-inheritance.html#faq-24.1)

Hab's jetzt auch geschafft, das Ganze zu kompilieren. Das Problem war nur, dass der Template-Platzhalter T der Oberklasse außerhalb der Klassendeklaration der Unterklasse nicht bekannt war. Implementierungen in die Deklaration gesteckt und es funktioniert.

durch private vererbung kann man natürlich die nicht "benötigten" methoden verbergen, aber nach außen signalisiert man so, dass ein stack im grunde eine liste sei, der lediglich einige methoden fehlen. das steht in starkem kontrast zum konzept der polymorphie, dass tochterklassen sich auch wie oberklassen verhalten können.

Is doch wurscht wenn man private ableitet, an die Superklasse kommst du ja bei private Vererbung (von aussen) nicht dran.

Weder Slicing noch Casten noch implizite Konvertierung funktionieren -- von daher sehe ich kein Problem.

@moagnus:
Du hast ein const zuviel geschrieben (T& Stack<T>::top() const <- das gehört weg), und 2x return vergessen. Rest sieht OK aus.

Is doch wurscht wenn man private ableitet, an die Superklasse kommst du ja bei private Vererbung (von aussen) nicht dran.

das stimmt schon, aber ich halte das konzept der privaten vererbung eh für ne krücke. vererbung sollte immer public sein, weil vererbung eine semantische beziehung darstellen sollte.

@moagnus: Nur für's nächste Mal - du solltest auch dazuschreiben, welche Fehler du bekommst, das erleichtert es uns, dir hilfreiche Tips zu geben

(btw: Listenelement ist privat in Liste<> und darum außerhalb der Klasse nicht verwendbar. Da ist es egal, wie du die Zugriffsrechte setzt ;))

am besten wäre es, das ganze wie einen stl adapter aufzubauen

die bekommen die darunterliegende implementation als template parameter, und dann kann man einen stack einfach per list/vector/dequeue implementieren lassen, je nachdem was man grade gut gebauchen kann

stack sollte wenn möglich nicht von liste erben

Wo liegt das Problem, wenn doch per Vererbung bzw. Delegation ungültige Methoden umgangen/ausgeblendet werden?

Deshalb plädiere ich ebenfalls dafür, solche Beziehungen nur dann über private Vererbung zu lösen, wenn es nicht anders geht.

@CStoll: Jepp, hast Recht. Ich wollte allerdings erstmal wissen, ob das prinzipiell funktioniert. Danach hätte ich euch an meinen Codeproblemen teilhaben lassen.

Dann ist ein "wie man sieht, produziert das einige Fehler" nicht gerade die richtige Art, auf dein Problem hinzuweisen

stack sollte wenn möglich nicht von liste erben

Wo liegt das Problem, wenn doch per Vererbung bzw. Delegation ungültige Methoden umgangen/ausgeblendet werden?[/quote]Die private Vererbung ist hier unnötig, weil Stack keinen Zugriff auf Features braucht, die außerhalb der öffentlichen Liste-Schnittstelle liegen. Außerdem schaffst du dir damit nur unnötige Abhängigkeiten.

Tatsächlich hat einfache private Vererbung (bei Mehrfachvererbung entstehen ganz andere Probleme um die es hier ja nicht gehen soll) potentiell einige Vorteile:
- Falls die die Basisklasse am Ende Padding aufweist, kann dieser Speicher für Member in der abgeleiteten Klasse genutzt werden, somit wird das Gesamtobjekt ggf. kleiner.
- Alle Funktionen, die per using nutzbar gemacht werden, sind unmittelbar die der Basisklasse. das bedeutet bei Templates weniger instantiierte Funktionen und mag in manchen Fällen zu besserem inlining führen, da Compiler dort üblicherweise ein Limit haben hinsichtlich verschachtelter Funktionsaufrufe.

Auf der anderen Seite wird der Code mit Vererbung an manchen Stellen etwas schlechter lesbar, weil wir dort, wo wir eine Funktion in der abgeleiteten Klasse durch eine gleichen Namens ersetzen, mit Casts oder qualifizierten Bezeichnern arbeiten müssen, wo sonst einfach ein Member stehen würde.

Ich kann nicht erkennen, das eine Variante zu größeren Abhängigkeiten als die Andere führt.

So gesehen, kann ich hier keine klare Empfehlung für oder gegen private Vererbung ableiten: das muss eine Entscheidung des Einzelfalls sein, je nachdem wie diese sich auf die Qualität der Implementation dann konkret auswirkt.

Ansonsten... danke für die Antworten. Ich dachte mir schon, dass ich bei dem Thema nicht unbedingt 'ne Pauschallösung fordern kann.

Die einzige "Abhängigkeit" bzw. Gefahr die ich beim privat Ableiten sehe ist: wenn die Basisklasse nicht "stabil" ist, dann kann das "using" zu einem Problem werden: es werden halt alle Overloads sichtbar gemacht, auch ggf. neue die man garnicht haben wollte als man die Klasse programmiert hat.