Discussion :

[ttone]

Hello,

Cette question est un peu redondante je crois, MAIS je reviens du graphique de choix de conteneurs dispo sur AF, je m'en suis servi pour un soft, et bien bon au final je tombe sur <vector>, à la place de mes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Type** pTab;

Qu'est ce que ca m'apporte au final ?
PArceque pour les queue, les list, les stack, ... je vois bien, mais pour vector ?...

[koala01]

Salut,

L'avantage, c'est qu'un std::vector va gérer "tout seul" tout ce qui est si susceptible de poser problème avec l'utilisation "classique" des pointeurs et des pointeurs de pointeurs: tout ce qui a trait à l'allocation (ou la libération) de mémoire dynamique, à la gestion de la taille du tableau, etc. .

En effet, tout ce qui est propre à la gestion des éléments contigus en mémoire se fait de manière strictement transparente, et tu n'a donc plus à t'inquiéter de maintenir "par toi même" la taille du tableau, l'allocation dynamique de la mémoire et la copie "correcte" lorsque tu veux rajouter un élément ou la libération de la mémoire lorsque la variable cesse d'exister.

Tout cela te permet donc de te concentrer sur ce qui est réellent important au lieu de "perdre du temps", entre autre en débuggage" à gérer par toi même des choses à ce point redondantes qu'il est possible de fournir des comportements génériques

La seule chose à laquelle il faille faire attention, c'est le cas où tu déciderais de maintenir un std::vector dont les éléments sont eux même des pointeurs sur "quelque chose"...

Si tu décide de prendre la responsabilité de l'allocation dynamique de la mémoire pour ces éléments, elle va bien évidemment de pair avec la responsabilité de libérer correctement (et en temps utiles) cette mémoire

[r0d]

Autres avantages:

- la classe vector fourni tout un tas de fonctionnalités (fonctions membres) qui en facilitent la manipulation et l'efficacité (iterateurs, clear, reserve, etc.)
- cette classe implémente certains patrons et idiomes qui lui permettent de s'intégrer parfaitement dans le reste de la lib standard. Ainsi donc, on peut utiliser diverses fonctionalité de la lib standard sur un vector sans se poser de questions (voir par exemple l'en-tête <algorithm>)

ensuite, des avantages plus personnels (qui ne font donc pas l'unanimité):
- lorsqu'on est habitué à la poo, on est plus "à l'aise" à manipuler des objets que des tableaux et autres pointeurs.
- la standardisation du langage. En utilisant une classe vector (sous réserve d'utiliser un "bonne" implémentation de la STL), tu es certain de respecter les standard, ce qui a l'avantage (pour moi très important) d'être sur de ne pas faire trop de conneries sans avoir besoin d'y réfléchir.

My cent.

[koala01]

En outre, si tu te pose la question au sujet de std::vector, tu peux te poser exactement la même pour toute la S(T)L...

Car, si tu prend la peine d'y réfléchir, toute la STL n'est, en définitive, qu'une implémentation générique particulière (en cela qu'elle respecte la norme, même si c'est avec plus ou moins de bonheur) de concepts qui sont propre à la programmation structurée, y compris sans orientation objet...:

• std::stack n'est que l'implémentation d'une pile d'objets (système LIFO)
• std::queue n'est que l'implémentation d'une file d'objets (système FIFO)
• std::list n'est que l'implémentation d'une liste doublement chainée
• std::set n'est que l'implémentation d'un arbre binaire, dans lequel l'objet maintenu fait office de clé
• std::map n'est que l'implémentation d'un arbre binaire "associatif" (pour lequel on peut utiliser une clé différente de l'objet en lui-même)
• tu as compris le principe pour les autres

Tous ces concepts sont - normalement - archi simples à mettre en oeuvre, ne serait-ce que de manière incomplète ou non générique (sans doute un peu moins s'il s'agit d'en fournir une implémentation générique et / ou qui respecte la norme, quil faut déjà arriver à comprendre )

[ttone]

Très bien j'ai compris.

Simplement avec le graphe de choix de conteneurs, je me rends compte que pour certains de mes tabeaux, je n'ai même pas besoin des méthodes des vectors : par exemple un tableau de 10 entiers pour un code à 10 chiffres : l'utilisateur entre son code, je check, ou par exemple un jeu de loto, ou une mesure physique, n'importe quoi.

Pour ca même un vector, c'est trop.

D'où mon interrogation...

Hors sujet :
Boost deviendrait la prochaine STL... cela veut il dire que les signals/slots svont être standardisés ?

[Davidbrcz]

Boost deviendrait la prochaine STL... cela veut il dire que les signals/slots svont être standardisés ?

Non, boost reste boost et la STL la STL.
Par contre, des morceaux de boost vont être intégrés dans la STL, mais pas boost::signal à ma connaissance.

Faudrait confirmer avec le draft, qui est feature-complet.

[JolyLoic]

Pour ca même un vector, c'est trop.

Il y a deux cas où vector est "trop" :
- Les tableaux de taille fixe, connue à la compilation, équivament d'un int i[12] : pour ça, il y a boost::array / std::tr1::array / std::array quand c++0x sera sorti.
- Les tableaux de taille fixe connue à la création utilisés localement et pouvant être alloués sur la pile, équivalent des variable length arrays du C99. Pour ça, il n'y a pas de remplaçant dans le C++ actuel, ni probablement en C++0x.

A part ces deux cas, vector n'est pas trop, il présente des avantages par rapport à de la mémoire allouée à la main, et pas d'inconvénient.

Boost deviendrait la prochaine STL... cela veut il dire que les signals/slots svont être standardisés ?

Des bouts de boost sont intégrés. Pas tous. Pas signal/slots, mais function fait partie du TR1 et de C++0x, et à partir de function, le plus gros du travail est fait pour avoir signal/slots.