Tu n'hériteras pas de std::vector

Question

Ok, c'est vraiment difficile à avouer, mais j'ai une forte tentation en ce moment d'hériter de std::vector .

J'ai besoin d'environ 10 algorithmes personnalisés pour le vecteur et je veux qu'ils soient directement membres du vecteur. Mais naturellement, je veux aussi que le reste des algorithmes du vecteur soient des membres du vecteur. std::vector de l'interface. Eh bien, ma première idée, en tant que citoyen respectueux de la loi, était d'avoir une std::vector membre en MyVector classe. Mais alors je devrais manuellement reprovider toute l'interface de std::vector. Trop de choses à taper. Ensuite, j'ai pensé à l'héritage privé, de sorte qu'au lieu de fournir à nouveau des méthodes, j'écrirais un groupe de using std::vector::member dans la section publique. C'est également fastidieux en fait.

Et voilà, je pense vraiment que je peux simplement hériter publiquement de std::vector mais prévoyez un avertissement dans la documentation indiquant que cette classe ne doit pas être utilisée de manière polymorphe. Je pense que la plupart des développeurs sont suffisamment compétents pour comprendre que cette classe ne doit pas être utilisée de manière polymorphe de toute façon.

Ma décision est-elle absolument injustifiable ? Si oui, pourquoi ? Pouvez-vous proposer une alternative qui aurait les membres supplémentaires suivants en fait mais qui n'impliquerait pas de retaper toute l'interface du vecteur ? J'en doute, mais si vous le pouvez, je serai heureux.

En outre, outre le fait qu'un idiot peut écrire quelque chose comme

std::vector<int>* p  = new MyVector

Y a-t-il un autre réaliste péril dans l'utilisation de MyVector ? En disant réaliste, j'écarte des choses comme imaginer une fonction qui prend un pointeur sur le vecteur ...

Eh bien, j'ai exposé mon cas. J'ai péché. Maintenant c'est à vous de me pardonner ou pas :)

Answer 1

En fait, il n'y a rien de mal à ce que l'héritage public des std::vector . Si vous avez besoin de ceci, faites-le.

Je suggère de ne le faire que si c'est vraiment nécessaire. Seulement si vous ne pouvez pas faire ce que vous voulez avec les fonctions libres (par exemple, vous devez conserver un certain état).

Le problème est que MyVector est une nouvelle entité. Cela signifie qu'un nouveau développeur C++ doit savoir ce que c'est avant de l'utiliser. Quelle est la différence entre std::vector y MyVector ? Laquelle est la meilleure à utiliser ici et là ? Que faire si je dois déplacer std::vector a MyVector ? Puis-je simplement utiliser swap() ou pas ?

Ne produisez pas de nouvelles entités juste pour donner une meilleure apparence à quelque chose. Ces entités (surtout si elles sont communes) ne vont pas vivre dans le vide. Elles vont vivre dans un environnement mixte où l'entropie augmente constamment.

Answer 2

L'ensemble de la STL a été conçu de manière à ce que les algorithmes et les conteneurs sont séparés .

Cela a conduit à un concept de différents types d'itérateurs : itérateurs const, itérateurs à accès aléatoire, etc.

Je vous recommande donc d'accepter cette convention et concevez vos algorithmes de manière à ce qu'ils ne se soucient pas de savoir quel est le conteneur sur lequel ils travaillent. - et ils n'auraient besoin que d'un type spécifique d'itérateur pour effectuer leurs opérations.

Aussi, permettez-moi de vous rediriger vers Quelques bonnes remarques de Jeff Attwood .

Answer 3

La principale raison pour ne pas hériter de std::vector publiquement est l'absence d'un destructeur virtuel qui vous empêche effectivement d'utiliser les descendants de manière polymorphe. En particulier, vous êtes pas autorisé a delete a std::vector<T>* qui pointe en fait vers un objet dérivé (même si la classe dérivée n'ajoute aucun membre), mais le compilateur ne peut généralement pas vous en avertir.

L'héritage privé est autorisé dans ces conditions. Je recommande donc d'utiliser l'héritage privé et de transférer les méthodes requises du parent comme indiqué ci-dessous.

class AdVector: private std::vector<double>
{
    typedef double T;
    typedef std::vector<double> vector;
public:
    using vector::push_back;
    using vector::operator[];
    using vector::begin;
    using vector::end;
    AdVector operator*(const AdVector & ) const;
    AdVector operator+(const AdVector & ) const;
    AdVector();
    virtual ~AdVector();
};

Vous devriez d'abord envisager de remanier vos algorithmes afin d'abstraire le type de conteneur sur lequel ils opèrent et de les laisser comme des fonctions à modèle libre, comme l'ont souligné la majorité des répondants. Cela se fait généralement en faisant en sorte qu'un algorithme accepte une paire d'itérateurs au lieu d'un conteneur comme arguments.

Answer 4

Si vous envisagez de le faire, c'est que vous avez déjà tué les pédants de votre bureau. Avec eux hors du chemin, pourquoi ne pas simplement faire

struct MyVector
{
   std::vector<Thingy> v;  // public!
   void func1( ... ) ; // and so on
}

Cela évitera toutes les erreurs possibles qui pourraient résulter d'un upcasting accidentel de votre classe MyVector, et vous pourrez toujours accéder à toutes les opérations vectorielles en ajoutant simplement un petit fichier .v .

Answer 5

Qu'espérez-vous accomplir ? Fournir simplement une fonctionnalité ?

La façon idiomatique C++ de faire cela est d'écrire des fonctions libres qui implémentent la fonctionnalité. Il y a de fortes chances que vous n'avez pas vraiment besoin d'un std::vector, spécifiquement pour la fonctionnalité que vous implémentez, ce qui signifie que vous perdez en réalité en réutilisabilité en essayant d'hériter de std::vector.

Je vous conseille vivement de regarder la bibliothèque standard et les en-têtes, et de méditer sur leur fonctionnement.