Est-il possible d'hériter de la mise en œuvre de conteneurs STL, plutôt que de déléguer?

Le risque est en libérant de l'aide d'un pointeur vers la classe de base (supprimer, delete[], et potentiellement d'autres méthodes de libération de la mémoire). Depuis ces classes (deque, carte, chaîne, etc.) n'ont pas de virtuel dtors, il est impossible de les nettoyer correctement avec seulement un pointeur vers ces classes:

struct BadExample : vector<int> {};
int main() {
  vector<int>* p = new BadExample();
  delete p; //this is Undefined Behavior
  return 0;
}

Cela dit, si vous êtes prêt à vous assurer de ne jamais accidentellement ce faire, il y a peu d'inconvénient majeur, à l'héritage, mais dans certains cas c'est un grand si. D'autres inconvénients comprennent des affrontements avec la mise en œuvre des détails et des extensions (certains peuvent ne pas utiliser les identificateurs réservés) et de traiter avec ballonnement interfaces (chaîne en particulier). Toutefois, l'héritage est prévu dans certains cas, en tant que contenant des adaptateurs comme pile ont un membre protégé c (le conteneur sous-jacent-ils s'adapter), et c'est presque uniquement accessible à partir d'une instance de la classe dérivée.

Au lieu de l'héritage ou de la composition, envisager d'écrire des fonctions libres qui peut prendre soit un itérateur paire ou un conteneur de référence, et sur cette. Pratiquement tous les <algorithm> est un exemple de cela, et make_heap, pop_heap, et push_heap, en particulier, sont un exemple d'utilisation de fonctions libres au lieu d'un domaine d'un conteneur spécifique.

Utilisez le conteneur des classes pour vos types de données, et encore appeler des fonctions gratuites pour votre domaine spécifique de la logique. Mais vous pouvez encore atteindre une modularité à l'aide d'une définition de type, ce qui vous permet à la fois de simplifier les déclarant et fournit un point unique si une partie d'entre eux a besoin de changer:

typedef std::deque<int, MyAllocator> Example;
//...
Example c (42);
example_algorithm(c);
example_algorithm2(c.begin() + 5, c.end() - 5);
Example::iterator i; //nested types are especially easier

Avis de la value_type et l'allocateur peut changer sans affecter plus tard, le code à l'aide de la définition de type, et même le conteneur peut changer d'un deque à un vecteur.

Comme tout le monde l'a déjà dit, des conteneurs STL n'ont pas les destructeurs virtuels afin d'hériter d'eux est dangereux à mieux. J'ai toujours considéré que la programmation générique avec des modèles comme un style différent de OO - l'un sans l'héritage. Les algorithmes de définir l'interface dont ils ont besoin. Il est aussi proche de Duck-Typing que vous pouvez obtenir dans un langage statique.

De toute façon, j'ai quelque chose à ajouter à la discussion. La manière que j'ai créé mon propre template de spécialisations précédemment est de définir des classes comme suit pour l'utiliser comme base de classes.

template <typename Container>
class readonly_container_facade {
public:
typedef typename Container::size_type size_type;
typedef typename Container::const_iterator const_iterator;
virtual ~readonly_container_facade() {}
inline bool empty() const { return container.empty(); }
inline const_iterator begin() const { return container.begin(); }
inline const_iterator end() const { return container.end(); }
inline size_type size() const { return container.size(); }
protected: //hide to force inherited usage only
readonly_container_facade() {}
protected: //hide assignment by default
readonly_container_facade(readonly_container_facade const& other):
: container(other.container) {}
readonly_container_facade& operator=(readonly_container_facade& other) {
container = other.container;
return *this;
}
protected:
Container container;
};
template <typename Container>
class writable_container_facade: public readable_container_facade<Container> {
public:
typedef typename Container::iterator iterator;
writable_container_facade(writable_container_facade& other)
readonly_container_facade(other) {}
virtual ~writable_container_facade() {}
inline iterator begin() { return container.begin(); }
inline iterator end() { return container.end(); }
writable_container_facade& operator=(writable_container_facade& other) {
readable_container_facade<Container>::operator=(other);
return *this;
}
};

Ces classes exposent la même interface que un conteneur STL. Je n'ai comme l'effet de la séparation de la modification et de la non-modification des opérations en différentes classes de base. Cela a un très bon effet sur la const-correctness. Le seul inconvénient est que vous devez étendre l'interface si vous souhaitez utiliser ces avec les conteneurs associatifs. Je n'ai pas couru dans la nécessité de bien.

Virtuel dtors côté, la décision d'hériter de rapport contiennent une décision de conception en fonction de la classe que vous créez. Vous ne devriez jamais hériter conteneur fonctionnalité juste parce qu'elle est plus facile que contenant un récipient et ajouter un peu d'ajouter et de supprimer des fonctions qui semblent comme simpliste wrappers sauf vous pouvez définitivement dire que la classe que vous créez est une sorte de conteneur. Par exemple, une classe de classe contiennent souvent des étudiants des objets, mais une salle de classe n'est pas une sorte de liste d'élèves pour la plupart des fins, de sorte que vous ne devriez pas être hérite de la liste.

Le transfert des méthodes inline loin, de toute façon. Vous ne serez pas obtenir de meilleures performances de cette façon. En fait, vous obtiendrez probablement une dégradation des performances.