L'avantage de passer par une lib telle que la STL, c'est de pouvoir utiliser tout ces algos "de base" avec des opérateurs personnalisés, ce qui est bien pratique quand on veut trier des choux-fleurs.
C'est sûr, mais (i) est-ce que ça arrive si souvent que ça de vouloir trier ou additionner des choux-fleurs, par rapport à trier ou additionner des nombres ou des chaines de caractères, et (ii) techniquement, je ne vois que peu d'exemples où on veut réellement trier des choux-fleurs selon leur chou-fleuritude : on veut les trier selon leur taille, selon leur couleur, selon tout un tas de trucs qui s'expriment par leur valeur numérique.
Après, je ne critique pas l'existence d'une STL, qui reste un outil utile dans des cas assez spécifiques. Ce que je critique, c'est le paradigme de programmation qui consiste à faire des appels non-standard à des fonctions triviales dont tout le monde a besoin, et qui elles font des appels à la bibliothèque standard.
Par exemple, M. Dupont va programmer une fonction somme(iterator, iterator) qui va appeler std::accumulate; alors que M. Smith va programmer une fonction sum(vector) qui va appeler std::accumulate. Bref, les deux ont les mêmes besoins, ils appellent les mêmes fonctions standard en arrière plan, mais leur interface n'est pas standard. Ça duplique les efforts, ça rend le code plus difficile à maintenir et à lire, les fonctions résultantes ont peut-être des bugs ou elles ne sont peut-être pas optimales. Je ne vois pas du tout l'intérêt d'intercaler les couches de trucs standard et de trucs non-standard.
Il est évident que si la bibliothèque standard possède des fonctions min() ou sum(), elles ne vont pas toujours se comporter comme le programmeur souhaiterait qu'elles se comportent. Dans ce cas, il faudra de toutes manières repasser par la STL ou équivalent, avec un commentaire du style // je veux le plus petit élément qui ne soit pas 0, alors que la fonction min() renvoie 0. Mais dans 95% des cas, ces fonctions se comporteront exactement comme il faut, et ça fera gagner un temps fou à tout le monde. Je trouve déraisonnable d'estimer qu'un programmeur sur un langage bas-niveau n'a que ça à faire que de chercher dans la littérature l'algorithme optimal pour réaliser telle ou telle tâche triviale.
[^] # Re: Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par arnaudus . En réponse à la dépêche Le langage D. Évalué à 2.
C'est sûr, mais (i) est-ce que ça arrive si souvent que ça de vouloir trier ou additionner des choux-fleurs, par rapport à trier ou additionner des nombres ou des chaines de caractères, et (ii) techniquement, je ne vois que peu d'exemples où on veut réellement trier des choux-fleurs selon leur chou-fleuritude : on veut les trier selon leur taille, selon leur couleur, selon tout un tas de trucs qui s'expriment par leur valeur numérique.
Après, je ne critique pas l'existence d'une STL, qui reste un outil utile dans des cas assez spécifiques. Ce que je critique, c'est le paradigme de programmation qui consiste à faire des appels non-standard à des fonctions triviales dont tout le monde a besoin, et qui elles font des appels à la bibliothèque standard.
Par exemple, M. Dupont va programmer une fonction somme(iterator, iterator) qui va appeler std::accumulate; alors que M. Smith va programmer une fonction sum(vector) qui va appeler std::accumulate. Bref, les deux ont les mêmes besoins, ils appellent les mêmes fonctions standard en arrière plan, mais leur interface n'est pas standard. Ça duplique les efforts, ça rend le code plus difficile à maintenir et à lire, les fonctions résultantes ont peut-être des bugs ou elles ne sont peut-être pas optimales. Je ne vois pas du tout l'intérêt d'intercaler les couches de trucs standard et de trucs non-standard.
Il est évident que si la bibliothèque standard possède des fonctions min() ou sum(), elles ne vont pas toujours se comporter comme le programmeur souhaiterait qu'elles se comportent. Dans ce cas, il faudra de toutes manières repasser par la STL ou équivalent, avec un commentaire du style // je veux le plus petit élément qui ne soit pas 0, alors que la fonction min() renvoie 0. Mais dans 95% des cas, ces fonctions se comporteront exactement comme il faut, et ça fera gagner un temps fou à tout le monde. Je trouve déraisonnable d'estimer qu'un programmeur sur un langage bas-niveau n'a que ça à faire que de chercher dans la littérature l'algorithme optimal pour réaliser telle ou telle tâche triviale.