Salut,
 
Je debute en C++ et je me suis lancé dans l'utilisation de la STL. Seulement j'ai un doute sur l'utilisation des iterateurs.  
 
Un exemple :

 
Voyant qu'il y a deux facons de faire pour lire le vecteur, j'ai d'abord pense que le premiere façon etait plus lente (donc pas bonne).  
Et bien, je me suis amuser à teste les 2 methodes sur de gros vecteurs et je n'ai vu aucune difference en terme de performances.
Alors, pourquoi on peux faire de 2 façons differentes et pourquoi je devrais utiliser des iterateurs (qui allourdissent l'ecriture et la comprehension du code) la ou je peux utiliser une simple boucle sur un indice ??

les iterateurs ne ralentissent ni n'alourdissent ni ne compliquent rien du tout: ils sont une manière générique et performante de parcourir et de manipuler des séquences d'objets, indépendamment de la représentation physique de la collection.
 
 
for(iter = vect.begin(); iter != vect.end() ; iter++)  
 
cela dit ceci est le pire exemple de mauvais emploi
 
iter=vect.begin() est OK
iter!vect.end() est tres mauvais car à moins que ta séquence soit modifier, tu appelles vector<T>::end() à chaque itération
iter++, un iterateur n'est pas un pauvre int, donc la post-incrémentation est beaucoup plus couteuse que la pré-incrémenation
 
la bonne ecriture est donc
 
const iterator seq_end(seq.end())
for(iterator i(seq.begin()); i != seq_end; ++i)
 
et à partir de ça tu peux commencer à comparer avec des accès classiques, notemment via index.

ça permet d'écrire un algorithme indépendamment de la façon dont sont stockées les données sur lesquelles il travaille: tu peux remplacer ton vector par un deque ou une liste, la version avec iterateurs reste valable alors que la version avec crochets demande au conteneur d'implementer l'accès aléatoire. Si ton algo se contente de parcourir une suite d'elt du premier au dernier, alors il n'y a pas de raison d'imposer au conteneur de fournir un accès direct au ième élément.
 
Dans la pratique... c'est vrai que les itérateurs c'est casse-couille à utiliser, ça a tendance à faire des lignes de 10km de long. Rien que l'ajout du mot-clef typeof au c++ ça améliorerait bien les choses, à mon avis.

ben les RTTI ca existe déjà via les <typeinfo> et typeid()

 
ouais mais c'est pas ça qui m'emmerde, c'est de devoir écrire
 

 
plutot que

rien t'empeche de faire des typedef si tu trouves ca trop long

 
Le problème du typedef, c'est justement de donner un nom. Chuis pas toujours inspiré et parfois il vaut mieux pas de nom du tout qu'un nom à la con. Accessoirement, le typeof évite aussi d'avoir à se rappeler du nom. Je n'y vois que des avantages.

ben faut wrapper et si tu te retrouves à devoir iterer 2 niveaux plus bas, c'est un problème de conception pas de facilité de langage

 
Je suis pas d'accord, ponctuellement ça peut arriver que tu ais besoin de vector de vector par ex., ça peut avoir son utilité, le type en lui-même est très explicite (mais trop long pour être tappé plus d'une fois sans devenir chiant) je ne vois pas ce que je gagnerais à tout noyer sous des typedef.

quand je dis wrapper, je parle pas seulement de typedef

Je ne vois pas ce que tu veux dire alors. J'ai regulièrement besoin de trucs du genre "std::vector< un_type_template< quelque_chose > >" , un bête conteneur quoi, je ne lui demande rien de spécifique, j'ai pas besoin de lui coller un nom ou des fonctionnalités particulières, par contre je passe mon temps à parcourir ses éléments. Comment faut-il faire dans ce cas ?

ben dans ce cas simple c'est sur qu'il y a que les typedef, mais des que j'ai un niveau de plus, c'est à dire plus qu'une simple colelction d'objet, je trouve toujours moyen de sous-typer et bien définir ces sous-types et leur opérations. ou je fabrique mes propres de itérateurs de A à Z pour pas m'embeter, et ça marche parfaitement (comme par exemple lorsque je veux faire une matrice et que je veux l'itérer)

Ok, je crois qu'en gros on est d'accord alors je vais plutôt aller manger un morceau (mais typeof c'est Bien )

[citation=299562,1][nom]Captain ad-hoc a écrit[/nom]Le problème du typedef, c'est justement de donner un nom. Chuis pas toujours inspiré et parfois il vaut mieux pas de nom du tout qu'un nom à la con. Accessoirement, le typeof évite aussi d'avoir à se rappeler du nom. Je n'y vois que des avantages.[/citationComplètement d'accord, ça devrait exister depuis longtemps !
Remarques, moi je voudrais mieux encore:

Ça ne me semble pas poser de problème particulier à la cohérence du langage...
 
 
Et dans cette catégorie, j'ai une autre question:
Pourquoi il n'y a pas de surcharges où un conteneur remplace une paire d'itérateurs debut/fin ?

Hein, pourquoi ?
Vu qu'on utilises si souvent les extrémités...