Discussion :

[r0d]

Bonjour à tous,

voilà, j'ai un petit problème intéressant qui se pose à moi, et il me semble qu'il esxiste plusieurs façons de procéder. J'aimerais donc avoir l'avis d'un maximum de personnes avant de faire mon choix.

La problématique est la suivante:
je dois développer un tableau, qui ressemblera fort au std::vector, à ceci près que:
1/ Tous les objets qui seront contenus dans ce tableau héritent d'une même classe dont certains champs sont connus. Il y a notamment un champ "name" de type string.
2/ Je dois rajouter quelques fonctionnalités "personnalisées", comme par exemple, récupérer un sous-tableau de tous les objets dont le champ "name" commence par une lettre donnée.
3/ Je tiens à implémenter un itérateur qui me permettra de parcourir ce tableau, ainsi qu'un opérateur de recopie pour le tableau.
4/ Tous les objets qui seront contenus dans ce tableau héritent d'une même classe, oui, mais ils risquent d'être assez différents, et d'hériter à plusieurs niveaux d'héritage.

Voilà, je pense que tout ce qui est important pour la conception est là. J'ai une petite idée de comment m'y prendre, mais je suis sûr que les votres seront meilleures

Merci pour vos propositions.

r0d.

[Invité]

std::map<std::string, ValType> ?

[r0d]

std::map<std::string, ValType> ?

oui bon, avec ça je pourrai faire la fonction dont je parle dans mon post, mais j'ai d'autres fontions plus farfelues à implémenter.
En fait, je pense qu'il va falloir que créé une classe et que je la fasse hériter de std::vector. Mais est-ce possible? Est-ce la bonne solution?

[Invité]

oui oui, hériter de std::vector est tout a fait possible, mais pour moi, d'apres ta description, tu as l'air d'avoir un tableau, donc plus que une seule dimension (d'ou ma proposition pour map<>).

[Pragmateek]

Hériter d'un conteneur de la STL est intéressant pour construire des conteneurs au fonctionnement quasi identique au conteneur de base.
Si après il faut redéfinir des méthodes du conteneur initial, en ajouter qui n'ont rien à voir avec celui ci ou ne jamais en utiliser certaines, enlève le bénéfice de l'héritage.
Dans ce cas il vaut mieux redéfinir un conteneur complètement nouveaux même si il faut réimplémenter les allocations mémoires et certaines fonctions de base.

[BertrandA]

Les destructeurs des conteneurs STL ne sont pas virtuels, choix d'implémentation.
Je trouve cet argument suffisant pour ne pas utiliser un conteneur comme classe de base : je privilégierais plutôt la composition.

[Ti-R]

Pourquoi meilleur, et meilleur que quoi ?

Lance toi, expose ton point de vu

Vu que le problème est bien posé, je ne pense pas qu'il y ait vraiment de problème.