§ 10 les conteneurs
"Et qui dit concept de boucle, dit accès aux éléments un par un"
Si on regarde que l’on introduit le mot pour la première fois dans ce chapitre, la phrase fait bizarre.
Il faudrait un liant pour introduire une définition d'itérer qui fasse intervenir (pas forcément à la première reformulation) le terme boucle.
Là, je ne suis pas hyper inspiré
Je ne parlerai pas de mémoire dans le cas des itérateurs. Typiquement les mots d’un fichier ne sont pas parcourus dans la mémoire mais dans le fichier.
Plutôt que debut_tableau
, je te propose curseur_tableau
.
Chipoteur que je suis, si on me dit "Si l’on part de std::end, on va se déplacer vers la droite ", je répondrai: "prends-moi pour un idiot, j’irai vers la gauche en décrémentant!".
Il faut AMA ouvrir une parenthèse de teasing sur les algorithmes et indiquer que "un grand intérêt de la SL et de ces itérateurs, c’est que le standard nous fournit ensuite des algorithmes qui parcourent (avec ++) des éléments pour faire des choses avec". Il serait dommage de devoir écrire ces algorithmes deux fois, une fois pour travailler en avançant, et une fois pour travailler en reculant. A la place, la SL offre un moyen de déguiser (d'adapter dans le jargon) les itérateurs qui avancent sur ++, en itérateur qui reculent sur ++. Ce sont ces reverse iterators que l’on obtient avec rbegin()
, rend()
.
Une autre raison est le fait que l’on travaille usuellement sur des plages semi-ouvertes [b, e)
. Travailler dans l’autre sens, change subtilement initialisation et condition de fin.
"Tous les algorithmes se trouvent dans le fichier d’en-tête <algorithm>, pensez donc à l’inclure."
Certains se sont perdus dans <numeric>
et ailleurs.
std::sort()
Exige des conteneurs qui supportent l’accès direct. Ce peut être une bonne occasion pour prendre le lecteur par la main et lui faire lire l’information correspondante sur cppreference, et déduire que cela marchera avec vector, array, queue, et T*, mais pas list, map…
"L’algorithme va déplacer toutes les occurrences de la lettre à la fin de la chaîne"
Nope.
Iterators pointing to an element between the new logical end and the physical end of the range are still dereferenceable, but the elements themselves have unspecified values
"La très grand majorité" -> "grande"
Les prédicats et foncteurs sous forme de fonctions, cela me gêne un peu car c’est la forme la moins efficace.
"Pourquoi pas un for
ou un while
?".
1- parce que c’était simple à rajouter, et que l’on était à la limite de la preuve de concept/faisabilité. Et surtout pour être complets, il le fallait — même si pratiquement personne ne s’en sert jamais.
2- ça devient intéressant avec le C++17 où std::for_each
est parallélisable de multiples façons différentes en standard là où les structures de contrôle passent par des standards (exemple typique: OpenMP) hors du périmètre du standard du c++ ; standards qui offrent de moins nombreuses façons de paralléliser.
"des algorithmes que nous n’avons pas encore vu"
J’accorderai bien "vu" au pluriel
"car retournant un pointeur sur, respectivement, le début et la fin d’une collection."
Si tu veux éviter le terme "itérateur", évite de trop recourir à "pointer" et "pointeur". Cela a des sens très forts. J’aurai tendance à utiliser "curseur". Et avec des dessins/des animations, on peut déplacer le curseur au fil des explications.
supprimer_espaces_gauche
et droit: cela vaudrait le coup de prendre par copie pour profiter de l’élision de copie & cie. Mais cela va demander un lien qui dit: "oui j’ai fait exprès de ne pas prendre une référence constante dans ce cas précis: explications derrière ce lien"