Version imprimable
Bonjour, :D
Pourquoi est-il ( ou serait-il ) préférable d'utiliser les vecteurs ( vector ) à la place des tableaux ??
Je n'ai pas trouvé de tutoriel sur le site concernant les vector.
Quelqu'un peut-il me donner un lien. ( ou me le prêter... )
merci
Claude
pour la simple raison que gérer un tableau a la main fait encourir des risques quant à la gestion de la mémoire.
par ailleur, un vector est un template, c'est à dire qu'il peut est adapté a nimporte quel type d'objet...
Merci,
quels genres de risques ...
et pourquoi un vecteur ne le pourrait-il pas ?
As-tu un tuto à ce sujet ?
:faq:
http://c.developpez.com/faq/cpp/?page=STL#STL_vector
C'est surtout moins lourd à utilisé qu'un tableau dans 95% des cas.
:D
merci pour ce lien, qui est excellent, et je suis justement en train de travailler dessus.
Mais j'aurais souhaité quelque chose de plus explicite (plus approfondi) sur la question.
J'ai cherché un peu partout et n'est rien trouvé.
:lol:
Je vais donner mon avis, réponse subjective donc.
Avantages des vectors (remarques valables pour les conteneurs en général):
- sécurité. Les conteneurs sont des classes epprouvées (utilisées depuis longtemps par de nombreux développeurs). S'ils sont utilisés correctement (utilisation d'iterateurs notamment) ils permettent de générer un code solide sans se poser de questions.
- simplicité. L'utilisation des conteneurs, après une rapide prise en main, est très simple (pas de gestion de mémoire, de types, manipulation aisée, etc.). Le temps gagné n'est pas négligeable.
- modularité/généricité. Les conteneurs (de la stl notamment) sont des templates. Ils permettent donc de gérer tous types d'objets de la même façon, sans se poser de questions.
- efficacité. Ces conteneurs sont le fruit de travaux des meilleurs développeurs depuis longtemps. Ils sont optimisés et leur utilisation est souvent préférable (d'un point de vue de la rapidité d'exécution) aux tableau de type C.
- dynamisme. Les tableaux dynamiques en c++ sont souvent délicats à implémenter, maintenir et sécuriser. Lorsque la taille du tableau est inconnue, cela ne pose aucun problème avec les conteneur.
- portabilité. Cette remarque est spécifique aux conteneurs de la stl et de boost (et elle s'applique également aux tableaux de type C, j'en conviens).
Voilà, c'est à peu près tout ce que je vois, mais c'est déjà pal mal non? ;)
Citation:
Envoyé par Claude URBAN
La réponse est simple: si tu n'as que quelques élements à peine une dizaine on prend un tableau statique [];
Mais c'est vrai que c'est pas "safe" si tu ne fais pas attention aux débordements..
Dans les gros projets on n'utilise pas trop les tableaux statiques mais , effectivement, les std::vector plutot pour allouer des objets à la demande..
Pour l'utilisation il y a la doc de SGI mais c'est pas très explicite...:oops:
bah, personnellement c'est devenu un reflexe. Même si je n'ai que trois valeurs, j'utilise un vector :oops: , mais je suis d'accord que c'est mieux avec un petit tableau de type C ... s'il n'y en a que deux, je vais tout de même utiliser une std::pair :)
J'ai du mal à voir l'intéret du tableau C par rapport au std::vector, meme pour des tableaux de petite taille.Citation:
Envoyé par r0d
Dans le cas où on a droit au bibliothèques externes, boost::array a la meme sémantique que les tableaux C et est beaucoup plus compatible avec les algorithmes de la SL.
Un tableau mode "C" pour faire un traitement important de donnés comme du traitement d'image. C'est super facile à manipuler et très rapide, et la syntaxe n'est pas lourde.
La c’est que mon point de vue :D
Les algorithmes de la STL sont facilement applicables aux vecteurs, ce qui constitue un grand plus.
Perso je prefere largement un tableau dynamic a un vecteur (surtout pour tout cequi est traitement de signale,spectre, imagerie ...). Pour moi la stl c'est nikel pour les contener plus complex comme les list,map ...
As deja avec Visual 6 debugé quand il y as des vecteurs (pareil pour les autre contener)? c'est une horreur. Je sais pas si c'est pareil avec d'autre debugeur.Citation:
Envoyé par r0d
Un pote chercheur en compilation m'as expliqué que les template sont tres mal optimisé par les compilateur actuelle et ne sont donc pas si performante que cela. D'ou plustôt utilisé un tableau dynamic si tu veut des perf (Peut etre que je me trompe :? )Citation:
Envoyé par r0d
Perso un petit tableau dynamic je trouva ca beaucoup plus simple qu'un vecteur.Citation:
Envoyé par r0d
Apres ca depend ce que tu doit faire avec. Si ton tableau change de taille tres souvent et que tu n'as pas l'habitude des tableau dynamique, je pense qu'un vecteur est plus interessant oir memeune list.
Les templates en C++ servent juste au compilateur à écrire ton code à ta place, comme si tu l'avais toi-même écrit. Je ne vois pas ce que cela à faire avec l'optimisation... vu que les classes seront réécrites et compilées comme le reste de ton code.Citation:
Un pote chercheur en compilation m'as expliqué que les template sont tres mal optimisé par les compilateur actuelle et ne sont donc pas si performante que cela. D'ou plustôt utilisé un tableau dynamic si tu veut des perf (Peut etre que je me trompe )
A ce que j'avais compris, les compilo ne sont pas reellement capable d'optimisé les templates. Apres c'est pas mon domaine. Mais tans que personne ne me prouve le contraire, je fait attention a ca.Citation:
Envoyé par Ti-R
Faudrait que j'essai avec deux code different pour voir si il as reellement des difference de perf un de ces jours.
Plusieurs choses.
a- D'abord une petite piqure de rappel sur les diverses structures buffers qui ont des éléments contigus.
* les tableaux statiques.
+ sur la pile => rapide
+ la dimension est statiquement connue => on peut utiliser simplement des choses comme boost::begin() et boost::end() pour itérer sur les éléments
- sur la pile => peut saturer la pile avec seule conséquence un core dump non esquivable
- non redimensionnable => pas adapté à la manipulation de buffers dont la taille ne peut être connue qu'à l'exécution (exemple type: inadapté à la lecture de lignes dans un fichier)
- tous les éléments sont obligatoirement construits, IIRC
- Très certainement la plus grande source de failles de sécurité : les codeurs étant des fainéants qui ne font jamais tous les tests de validité qui devraient être faits, on se retrouve vite avec des buffer overflows sur la pile, voire à de l'injection de code, dans les exemples les plus scolaires.
+ Mémoire automatiquement collectée à la fin de la portée, quelque soit le chemin de sortie emprunté
* boost::array<>
-> tout pareil, mais avec une couche d'"abstraction" supplémentaire qui apporte l'interface STL-isante.
* Les VLA (Variable Length Arrays)
-> même principe que les tableaux statiques
+ la dimension peut n'être déterminée qu'à l'exécution
- n'existent qu'en C99, ne font et ne feront jamais parti du C++
* Les tableaux dit "dynamiques"
- sur le tas => plus lent lors de l'allocation
+ S'il n'y a plus de mémoire, on se prend une exception (new[]) ou un pointeur nul (*alloc), le programme ne plante pas sans que l'on ne puisse rien faire contre.
+ dimension déterminée à l'exécution
+ redimensionnables si on utilise les fonctions d'allocation C (malloc, realloc, ...)
- non redimensionnables si on utilise les fonctions d'allocation du C++ (new[]).
- donc, non redimensionnables si utilisés pour des objets (les *alloc ne sont utilisables que sur les types POD -- pour les utiliser sur des types non-POD, il faut une étape de construction supplémentaire, ce qui revient à réinventer std::vector)
- Les données contenues doivent être default constructible -- particulièrement important pour les objets qui ne sont utilisables qu'avec new[]. Les types POD ne sont pas initialisés, que cela soit avec les *alloc ou new[].
- la mémoire doit être explicitement collectée à la main ; ce qui est un énorme problème en situation où on l'on peut sortir d'une portée par n'importe quel chemin (return ou exception). Les returns, on peut les maitriser, les exceptions pas aussi simplement.
~ pas de sémantique d'entité ou de valeur qui lui soit propre. Bien que plutôt orienté entité, parce que pointeur.
* les std::vector<>
- sur le tas => plus lent -- pratiquement tout pareil que pour new[].
~ Sauf que la phase de construction peut être décorrélée de l'allocation
+ les objets stockées n'ont pas la contrainte d'être default constructible
~ les données POD sont toujours 0-initialisées sur un resize, ou lors de l'appel au constructeur prenant une taille
+ interface STL-isante pour itérer
+ S'il n'y a plus de mémoire, on se prend une exception, le programme ne plante pas sans que l'on ne puisse rien faire contre.
+ redimensionnables
+ la mémoire est implicitement collectée à la sortie de la portée, c'est le principe du RAII (=> FAQ)
- aujourd'hui, en l'absence d'applicabilité des NRVO & RVO, on peut parfois payer une recopie sur un return d'un vecteur
+ demain, si tout va bien, ils disposeront d'une constructeur à sémantique de déplacement => jamais de copie, même quand RVO & NRVO ne sont pas applicables.
+ en accès, 0 surcout supplémentaire par rapport à ce qui a été alloué avec new[].
~ sémantique de valeur.
+ Coutent moins cher à faire passer en paramètre (référence constante ou non) car la taille circule avec le pointeur -- oui, c'est une optimisation ridicule.
Ce que j'ai mis en rouge est ce qui fait que j'utilise quasi exclusivement les vecteurs. Les exceptions existent, je les utilise. Sécuriser un code, manipulant diverses ressources dans un contexte où les exceptions sont à tous les tournant, est vite infernal sans le RAII. Les vecteurs sont leur incarnations, dédiées à la gestion de buffers et autres ensembles d'objets contigus.
L'autre avantage qui fait que je préfère leur utilisation là où les performances sont critiques, c'est pour la redimensionabilité qui est plus agréable à gérer qu'avec realloc.
b- Pour les perfs. Comme d'hab, beaucoup de légendes urbaines => goggle: "n1666 filetype:pdf".
Si l'inlining n'est pas désactivé à la compilation, alors utiliser un vecteur, c'est exactement comme si on utilisait directement le même code. Faire un for pour itérer sur un buffer géré avec un vecteur doit couter le même prix que faire un for pour itérer sur un buffer géré avec new[]/delete[].
C'est surtout le prix de l'allocation qui est très légèrement différent vu que le vecteur fait plus de choses comme décorréler allocation et construction. Suivant les cas, le new sera plus efficace (typiquement sur les types POD), suivant les cas beaucoup moins efficace (car on aura payé une construction par défaut en plus).
Il serait certes possible de plus optimiser encore, la phase initiale, pour avoir un conteneur dédié .. qui ne serait donc plus générique.
Mais comme je l'ai dit, j'utilise dans un contexte fortement temps réel des vecteurs que je redimensionne à chaque passage dans une boucle. C'est toujours plus efficace que l'approche naïve qui fait un nouveau new. Et je trouve que j'y gagne plus en sécurité et productivité que ce que j'y perds en performances.
c- VC6 commence à rejoindre les ancêtres. Il précède la norme d'un an je crois, il a donc 9 ans bientôt, et il n'est plus maintenu par Microsoft. A part sur les projet qui ont commencé il y a plus de 5 ans, il ne se justifie plus aujourd'hui.
Quant aux vecteurs, certes il manquait quelques petites fonctionnalités, mais ils marchaient déjà très bien. Et de plus, il était tout à fait possible d'investir dans une meilleure SL -- pour ce que cela coutait...
d- Conclusion, par défaut, le RAII est mon ami, et les vecteurs aussi. Je vois un peu les vecteurs comme la solution pour les fainéants qui savent que le C++ n'est pas le C, et qui veulent un code qui ne fuit pas sans avoir à se prendre le choux avec les exceptions.
PS: désolé pour les néologismes.
PPS: il peut manquer des trucs
PPPS: "je ne ferai pas ça tous les jours."
Bonsoir à tous, :D
Whaoo !!! :hola: :hola: :hola: :hola:
Je ne sais que dire ?
Je suis complètement soufflé...
Je ne m'attendais pas, avec cette simple petite question, à soliciter autant de réactions et encore moins à obtenir autant d'explications :king:, même si je n'ai pas encore tout compris :oops: , plus particulièrement l'exposé de Luc (... chapitre 2, acte III, verset 25 ...) qui pour le moment est au-delà de mes capacités intellectuelles en la matière... mais je ne désespère pas. :P
Il ne me reste plus qu'à lire et relire pour bien approfondir, essayer, autant que faire ce peut, de bien comprendre :fou: et ... de mettre en application.
Grand :merci: :merci: encore à tous ceux qui ont consacré de leur temps à me répondre.
Et @++, car j'ai encore bien des lacunes et j'y reviendrai très certainement.
Claude
C'est bien dommage... car il y a encore beaucoup d'autres sujets obscures. :mouarf:Citation:
PPPS: "je ne ferais pas ça tous les jours."