Discussion :

[Magorath]

Bonjour tout le monde,

J'ai une petite question concernant la STL et plus particulier les valarray. Est-ce qu'on peut considérer ces derniers comme des remplaçant du tableau "classique" comme par exemple int tableau[5]; ?

Une deuxième question que je me posais était de savoir pour quel raison les concepteurs de la STL ont choisis d'empêcher de prendre les conteneurs comme classe de bases (puisque leurs destructeurs ne sont pas virtuels) ?

Merci d'avance pour vos réponses.

[Klaim]

J'ai une petite question concernant la STL et plus particulier les valarray. Est-ce qu'on peut considérer ces derniers comme des remplaçant du tableau "classique" comme par exemple int tableau[5]; ?

Je connais pas les valarray (ça existe dans la STL ça O__o?) mais l'équivalent d'un tableau tel que tu le décris est un std::vector. Il a toutes les mêmes caractéristiques sauf qu'il connais sa taille (nombre d'elements) et qu'il peut augmenter de taille dynamiquement (et autres spécificitées à connnaitre si tu as précisément besoin de savoir ce qu'il se passe en mémoire).

Une deuxième question que je me posais était de savoir pour quel raison les concepteurs de la STL ont choisis d'empêcher de prendre les conteneurs comme classe de bases (puisque leurs destructeurs ne sont pas virtuels) ?

Parceque le but c'est de les utiliser, pas d'en faire des variantes. Un conteneur de la STL est écrit et spécialisé pour "contenir" selon sa propre philosophie (list, vector, map, etc). Les objets qui ont besoin de gerer des groupes d'autres objets peuvent se servir de ces conteneurs pour contenir les objets pendant qu'eux s'occupent de les gérer.

Conceptuellement parlant, hériter une classe d'une classe conteneur, c'est un peu comme utiliser son propre ventre comme si c'était un sac. C'est inadequate.

Bon en fait ya aussi des raisons techniques il me semble, mais je ne me souviens plus des détails.

[Magorath]

Pour ma question concernant la dérivation des classes de conteneur, c'est justement les raisons techniques qui m'intéressent. Pouruoi ne pas le permettre si l'on veut créer un nouveau type de coneneur ayant des similitudes profondes avec un type pré-existant ?

[Kujara]

Pour ma question concernant la dérivation des classes de conteneur, c'est justement les raisons techniques qui m'intéressent. Pouruoi ne pas le permettre si l'on veut créer un nouveau type de coneneur ayant des similitudes profondes avec un type pré-existant ?

Rien ne t'en empeche.

Le manque de fonction virtuelle t'empeche juste de stoquer tes instances sur un pointeur / reference de la classe de base.

Et ce manque s'explique facilement par son inutilité et son cout point de vue perfs.

Apres tout, tu ne crée jamais de _xtree toi même, n'est-ce pas ? et pourtant, c'est une des classes de base de map ...

[Davidbrcz]

Pour répondre à Klaim:
Exemple de valarray: http://www.josuttis.com/libbook/num/val2.cpp.html

[JolyLoic]

valarray été prévu pour avoir une classe de tableaux avec lesquels faire du calcul numérique, par opposition à vector, qui est une classe plus générique.
Je ne les ai jamais vraiment utilisés, mais je crois que de l'avis général, ils n'étaient pas assez matures au moment de leur introduction dans le standard. En particulier, ils n'exploitent pas toutes les fonctions de gain de performance des templates, ce qui est disqualifiant pour une bibliothèque numérique.

Pour ce qui est de l'héritage des conteneurs de la STL, l'héritage a un coût. Si il ne sert à rien, pourquoi payer ce coût ? Si les vectors avaient eu un overhead clairement mesurable par rapport aux tableaux C, ils ne seraient jamais passés.

Tu peux faire du polymorphisme avec les vecteurs, simplement, ce sera du polymorphisme résolu à la compilation, et l'élément de base n'est pas le conteneur, mais l'itérateur.

Le principal problème que je vois en terme d'extensibilité, c'est que pour faire une classe semblable en fonctionnalité à un conteneur ou un itérateur, et compatible avec les algorithmes de la STL, il faut écrire beaucoup de code. Trop. Même si pour les itérateurs, boost::iterator permet d'alléger un peu ça.

[koala01]

Salut,

En plus, pour le point de vue technique, les différentes classes conteneurs sont des classes template...

Or le mécanisme meme des template empeche la virtualisation des méthodes (tu pourrait *éventuellement* utiliser le CRTP, par contre mais, en vaut-ce réellement la peine )

Dés lors, pas de destructeur virtuel, et donc, pas de polymorphisme possible (sans compter que comme indiqué plus haut, l'utilité de la chose n'est pas prouvée )

[ttone]

Vous confirmez que pour des opérations de type audio (additions, multiplication par constante, etc) les VALARRAYs permettent un traitement plus rapide ? en évincant visuellement et en niveau inférieur des incrémentations for ?