Marc Boyer a écrit :

  Sauf que bsearch ne travaille pas avec des listes,

J'ai employé le terme de liste dans un sens informel, ça ne change rien au problème, ce qui compte c'est qu'on ait une succession d'"objets" (au sens informel encore).

mais avec des
tableaux, et qu'avec l'arithméique des pointeurs, quand tu as
l'adresse d'une donnée (et son type), ben, t'a les voisins...

Je vois pas ce que l'arithmétique des pointeurs vient faire là-dedans. Tu n'as pas compris ma question.

Bien sûr que j'ai les voisins si bsearch répond != NULL. Mais si bsearch te renvoie NULL, c'est quoi le voisin ?????? pourtant il existe et dans sa recherche, bsearch le rencontre mais dans sa réponse, il l'ignore.


Je reprends l'exemple idiot déjà cité : je veux implémenter nextPrime à partir de la liste suivante

2, 3, 5, 7, 11, 13, 17, 19, 23, 29,
31, 37, 41, 43, 47, 53, 59, 61, 67, 71,
73, 79, 83, 89, 97.

Je demande à bsearch si 50 est dans la liste, il va faire une recherche dichotomique et il va finir par voir que 50 est entre t[14] et t[15]. Mais il va me répondre NULL, ce qui est une perte d'information car s'il me répondait par exemple 15 (enfin plutôt un pointeur vers l'élément numéroté 15 du tableau des nombres premiers ci-dessus), je saurais immédiatement si 50 est dans le tableau (suffit de comparer 50 avec t[15]) mais surtout j'aurais une information beaucoup plus consistante que NULL ! je saurais que nextPrime(50)=t[15], et ça pour le même prix.

Ce que je dis là ne me parait pas bien compliqué à comprendre.

  D'ailleurs, une recherche dichotomique dans une liste, ça
va être dur...

Tu fais une fixation ou quoi ? Avant d'aller faire tes courses au supermarché, tu te fais un _tableau_ de courses  ? Bon moi je fais une liste. C'est quoi une liste pour toi ? une liste chainée ? Ça reste une succession d'objets, je vois donc pas le problème.