sie wurden nicht darauf ausgelegt basisklassen zu sein, und du wirst grundsätzlich undefiniertes verhalten bekommen wenn du memberfunktionen überscheiben willst

undefiniertes Verhalten?
Stimmt das wirklich?
Wird nicht, wenn du eine Methode aufrufst die Methode des Objekt-Typs aufgerufen,
das zur Komipilierzeit ermittelbar ist? Also wenn du einen Zeiger auf dein Objekt
als vector hast, wird er (wegen der fehlenden V-Table) die Basisfunktion aufrufen,
falls du ein Zeiger auf MyClass hast, die überschriebene Funktion.

Ansonsten könnte man doch auch nicht privat von STL-Klassen ableiten, oder?

und eine Problem ist natürlich der fehlende virtuelle Destruktor, so dass ein Löschen
als Basisklassen-Typ ein Speicherleck verursacht.

Gruß,
CSpille

r0nny schrieb:

sie wurden nicht darauf ausgelegt basisklassen zu sein, und du wirst grundsätzlich undefiniertes verhalten bekommen wenn du memberfunktionen überscheiben willst

Da nur virtuelle Funktionen überschrieben werden können und diese Container keine virtuellen Funktionen haben ist das keine nützliche Feststellung.

template <class T, class A = std::allocator<T> >
class MeinVector : public std::vector<T, A>
{
    typedef typename std::vector<T, A>::reference reference;
    typedef typename std::vector<T, A>::size_type size_type;

public:
    // Range check index operator
    reference operator [] (size_type n)
    {
        return at(n);
    }
};

Ob das Sinn macht, ist eine andere Frage. Ich denke eher nein. Wobei man nicht gleiche alle Fälle ausschließen sollte.
z.B. neue Version eines Framework's steigt auf STL um, aus Kompatibilitätsgründen wird die schnittstelle angepasst.
Weitere Gründe von STL-Containern abzuleiten kenne ich nicht.

MfG
DDR-RAM

Macht meiner Meinung nach nie Sinn. Es gibt zum Einen keine protected Member auf die man zugreifen können möchte und zum Anderen kann man das ganze nicht polymorph benutzen, da der Destruktor und auch keine Methode virtuell ist.
Vielleicht versteh ich aber auch nur deine Begründung mit dem Framework falsch.

In der STL implementation meines Compilers wird das zb so gemacht, da wird erst eine Klasse std::list_base erstellt, und davon dann die list abgeleitet. Da das normalerweise niemand weis, bzw nicht auf die idee kommt, nen basisklassenzeiger darauf zu erstellen, ist das okay.

Ist allerdings nur in einer generischen Umgebung sinnvoll:

template<class T>
class Derived: public std::vector<T> 
{
    //operator[] const wird überschrieben
    const_reference operator [] (size_type n)const
    {
        return at(n);
    }
};

template<class Vector>
void foo(const Vector& vector);
template<class T>
void bar(const std::vector<T>& vector);

//in der main
Derived<int> foobar;
foo(foobar);//okay
bar(foobar);//autsch, impliziter basisklassencast, und die überschriebene                    
            //methode wird ignoriert, es herrscht wieder normales vector verhalten
           //würde jetzt der operator[] angewendet, wird kein range check mehr durchgeführt

Wo genau macht Stroustrup das?

Die C++ Programmiersprache, 4. Aufflage, Addison-Wesley. In §3.7.2.

Macht meiner Meinung nach nie Sinn.

Sag niemals nie

Es gibt zum Einen keine protected Member auf die man zugreifen können möchte

Nein aber public Methoden.

und zum Anderen kann man das ganze nicht polymorph benutzen, da der Destruktor und auch keine Methode virtuell ist.

Ja, kein Laufzeitpolymorphismus. Statischer Polymorphismus ist dennoch möglich.

Vielleicht versteh ich aber auch nur deine Begründung mit dem Framework falsch.

Könnte sein.
Ich nehme als Beispiel einfach die Klasse CAtlArray aus der ATL. Das ganze ist natürlich hypothetisch. CAtlArray und std::vector vertragen sich ja nicht, weil sie komplett verschieden sind.
Aber man könnte die Schnittstelle von std::vector auf CAtlArray umwrappen.

template <class T, class ETraits = CElementTraits<T>, class A = std::allocator<T> >
class CAtlArray : public std::vector<T, A>
{
/* vieles */

public:
    size_t GetCount() const throw()
    {   return  size(); }
    bool IsEmpty() const throw()
    {   return empty(); }

/* vieles */
};

10000ende Zeilen von Code, die bisher unter Verwendung von CAtlArray geschrieben wurden bleiben gültig. Dazu kommt, das man jetzt CAtlArray's überall dort verwenden kann, wo std::vector gefragt ist, weil CAtlArray nur einen Zweck erfüllt, std::vector aus Kompatibilitätsgründen zu wrappen. Daher sehe ich auch das Beispiel von otze als falsch an. Der implizite Basisklassencast ist nicht wirklich schlimm oder ungewollt.
Eine Funktion, die mit std::vector arbeitet und den ungeprüften Indexoperator verwendet, tut die in der Regel zurecht. (z.B. iteration über alle Indices)
Sonst würde sie auf einem std::vector mit gleichen Inhalt undefiniertes Verhalten auslösen.
Man erkennt schon an dem Beispiel, das die ganze Sache recht weit hergeholt klingt, aber irgendein Framework leitet tatsächlich von std::string ab, weiß dazu jetzt aber nichts genaueres.

MfG
DDR-RAM

// alter Code

void foo2(int& i, int j);

void foo(FW::CVector<int>& rVec)
{
    for (size_t i = 0; i < rVec.GetCount(); ++i)
        foo2(rVec[i], i);
}

//  fester Code, andere externe lib
void bar(std::vector<int>& rVec)
{
    for_each(rVec.begin(), rVec.end(), bar2());
}

//  und ein neu geschriebenes Code schnippsel

void foobar(FW::CVector<int>& rVec)
{
    //  nutze Framework-Funktionen
    foo(rVec);
    //  nutze externe lib
    bar(rVec); // private Vererbung, wäre hier nicht gut ;)
}

Das ganze ist natürlich sehr Bruchstückhaft und gestellt.

• private-Vererbung ist quasi eine Komposition mit gewissen Zusätzen:
  man kann auf protected-member zugeifen (entfällt bei der stl).
• Member können den Zeiger auf die abgeleitete Klasse zum Basisklassenzeiger konvertieren (bei der normalen Komposition erhält man übrigens auch sehr leicht einen Zeiger auf diese klasse),
• man kann virtual-methoden überschreiben (entfällt auch bei der stl),
• bei private-vererbung ist das durchreichen der Funktionen einfacher (weniger Zeichen im Code) als bei normaler Komposition,
• private-Vererbung bringt keinen Performance-Vorteil,
• private-Vererbung bringt mehr zusätzliche Abhängigkeiten

Was heißt das?
Wir können private-Vererbung außen vorlassen. Eine Komposition von stl-containern ist etwas sehr natürliches und muss hier auch nicht weiter erwähnt werden.
Nochmal zur Framework-sache:

• FW::CVector<int>* soll in std::vector<int>* implizit konvertiert werden können,
• Über FW::CVector<int>* soll direkt auf alle std::vector<int>* Methoden zugegriffen werden können
• FW::CVector<int> erweitert oder verändert die Schnittstelle von std::vector<int>

FW::CVector<int> ist ein std::vector<int> !

Sollte nicht die komplette Schnittstelle verfügbar sein soll, die std::vector<int> bietet, dann kann man das durch private-überdeckung regeln.
Falls FW::CVector<int>* nicht implizit in std::vector<int>* konvertiert werden können soll, dann ist natürlich eine Form der Komposition zu wählen.
z.B.

class CIntVectorMitZugriffsCounter : public std::vector<int>
{
public:
    int operator [](size_type n)
    {
        ++m_nCount;
        return  std::vector<int>::operator[](n);
    }

private:
    size_t m_nCount;
};

Richtig ist, dass das nicht sinnvoll ist, da std::vector<int> kein polymorher Typ ist. Hier ist, wie bereits erwähnt, eine Form der Komposition zu wählen.

edit:
Ich sage mal so, in der Regel ist das ableiten von STL-Containern einfach nur ein Anfängerfehler.