En news:48e3534c$0$29455$426a74cc@news.free.fr, candide va escriure:

Juste un avis perso : le retour de la fonction bsearch est peu
exploitable.

Euh, si tu cherches un élément dans une liste, le fait de te retourner un
pointeur vers cet élément, c'est assez exactement l'objectif recherché, non?

Bien souvent, face à une liste croissante, on ne se préoccupe pas
essentiellement de savoir si un élément donné s'y trouve ou ne s'y
trouve pas, on cherche à savoir où il est placé dans la liste (et
éventuellement hors de la liste à gauche ou à droite).

Cela dépend complètement de ce que tu veux faire avec ta « liste
croissante ». Si tu _recherches_ un élément qui est censé y exister, la
valeur retournée par bsearch me semble adaptée (et en anglais, rechercher se
dit "to search", et non, ce n'est pas un hasard ;-))

Si par contre tu as un autre objectif, peut-être préparer un tri par
insertion ou que sais-je, il est probable que la fonction bsearch sera
sous-optimale...

Or, quel que
soit l'algorithme utilisé par bsearch (recherche séquentielle ou
dichotomique), bsearch serait en mesure sans coût supplémentaire
excessif de donner cette position.

1) Tu tombes au bon moment pour proposer que la norme C1x inclut une
fonction fsearch() [f pour "fuzzy"]

2) C'est un peu comme avec les propositions des politiques, j'aime bien
connaître le détail, histoire de voir le coût réel du supplément « non
excessif » ; entre autres questions qui me viennent à l'esprit, serait-ce un
paramètre supplémentaire ? retourner une structure ? avec ou sans restrict ?
Ou, dans un autre domaine, y a-t'il des microcontrôlleurs avec la fonction
bsearch() câblée, ou des optimisateurs capables d'analyser le code pour
utiliser par exemple SCANS sur architecture 8086, qui auraient alors une
pénalité importante à l'utilisation de ta proposition alternative ?
[ L'histoire de scans est un exemple, je sais parfaitement qu'aujourd'hui
une telle optimisation ne serait pas rentable. ]

3) Tu dois évaluer l'utilité de cette amélioration (cas où elle apporte
réellement quelque chose en _plus_ de ce qui existe déjà), et le comparer
avec tous les cas similaires, y compris par exemple les algorithmes d'arbres
balancés (où ni l'une ni l'autre des deux fonctions ne s'appliquent) ; je ne
suis pas certain que le bilan global soit exceptionnel.

Hélas bsearch  se contente de
donner une réponse binaire. Et je trouve particulièrement agaçant
d'avoir à me recoder un truc aussi classique qu'une recherche
dichotomique, pas vous ?

bsearch est historique, elle doit avoir 30 ±2 ans...
Donc en 1987, il n'était plus question de proposer une alternative, la seule
question futde considérer si cela valait la peine d'avoir cela dans la norme
(difficulté de codage sans erreur, bon rapport poids/performance de mettre
telle ou telle fonction dans la bibliothèque standard, entre autres) ou pas
; bsearch(3) a passé la barre de même que qsort(3), mais pas leur homologue
lsearch(3) [recherche « linéaire » dans un tableau pas forcément trié].


Antoine