Discussion :

[laupt]

Bonjour,

je développe une appli en C sous Linux et je souhaite utiliser une liste chaînée.

Pour ne pas tout réécrire, j'ai cherché une API qui fournit déjà les fonctions de base, mais je ne sais pas trop quoi utiliser...

- La structure list_head ? Mais il faut include /linux/src/list.h et il me semble qu'il est déconseillé d'inclure un header du noyau côté user...
- glist, contenu dans la glibc ?
- insque et remque qui sont conforme POSIX, mais qui ne me paraissent pas très abouties (il faut préciser l'élément précédent lors d'une insertion, je ne vois pas de fonction de recherche directe, ...)

Quelle est la meilleure API pour les listes chaînées ?...

Merci !

[Vespiras]

Bonjour,

Quel type d'application veux-tu réaliser si ce n'est pas indiscret ?
Je ne vois pas en quoi inclure list.h serait gênant ... la librairie existe pour être utilisée ^^

[laupt]

Merci pour ta réponse.

En fait, mon processus reçoit des trames via une message-queue. Je dois les bufferiser pour les envoyer caractère par caractère. Je précise que certaines trames doivent s'insérer entre d'autres trames, et que certaines trames servent à indiquer qu'il faut supprimer une trame de ma liste.
Bref, la liste chaînée paraissait adaptée parce que je pouvais insérer une trame au milieu des autres, et supprimer facilement n'importe quelle trame de la liste.

Je ne voulais pas inclure list.h car j'ai vu ça : http://stackoverflow.com/questions/4...es-ubuntu10-10

" The header files you are using are designed for internal use of the Linux kernel. They were not designed to be used by a userland program."
"adding -I/usr/src/linux is a no-go, since unsanitized header files are not meant to be used from user programs" ....

libHX me fait inclure une librairie supplémentaire... je préférerais éviter...

[Bysbobo]

Et sinon pourquoi ne pas écrire les fonctions toi-même?

Tu en as au moins 3:
*/ Ajouter
*/ Supprimer
*/ Remplacer

Comme ça, tu peux les personnaliser et pas la peine d'avoir un truc dont tu n'es pas sûr que ça s'intègre non sans mal

[laupt]

Je voulais juste ne pas m’embêter à réécrire quelque chose qui existe probablement déjà, et qui serait déjà testé... mais si rien ne convient... alors je vais devoir le faire...

Et à propos de list.h : vous pensez aussi qu'il faut éviter d'utiliser des headers du kernel côté user ?... (remarque : quand j'essaye, j'ai des erreurs sur d'autres .h introuvables... et si un jour je change de noyau, je risque encore d'avoir les mêmes problèmes..)

[Bktero]

Bonjour,

Personnellement, j'utiliserai la Glib. Bien que je ne l'ai pas testée, mon aide-mémoire C conseille très souvent Glib et j'ai tendance à lui faire confiance. C'est par ailleurs une bibliothèque reconnue.

Intégrer des fichiers du noyau dans des programmes utilisateurs me semble aussi un peu scabreux. Une rapide recherche comme tu l'as déjà fait le confirme un peu.

Recoder soi-même... C'est s'embêter sans doute ^^ En effet, tu éviterais les problèmes d'intégration comme dit par Bysbobo

Comme ça, tu peux les personnaliser et pas la peine d'avoir un truc dont tu n'es pas sûr que ça s'intègre non sans mal

Mais tu dois tester et valider tes fonctions après les avoir implémenter. Et je pense que c'est pire que de simplement utiliser Glib ^^

[laupt]

Merci beaucoup, mais en fait, je pense utiliser plutôt les macros de /sys/queue.h : http://linux.die.net/man/3/queue
(Des exemples sont fournis ici : http://philpep.org/blog/21).

Celles-ci ne sont malheureusement pas POSIX, mais elles ont l'air bien complètes (gère les piles/files, simplement ou doublement chaînées, circulaires, ...).

Je ne connaissais pas, mais mieux vaut tard que jamais...!

[Vespiras]

D'ailleurs, je repassais sur le sujet, et vraiment à tout hasard, même si je pense que tu as surement trouvé le tuto, sur developpez.net il y a de bonnes explication à la création de ses propres fonctions Push(), Pop() ... :

http://chgi.developpez.com/pile/

Si l'envie te prend de réinventer la roue

[souviron34]

Si l'envie te prend de réinventer la roue

Même sans vouloir réinventer la roue...

Simplement vouloir un petit code portable, autonome, et sans dépendances...

Parce que bon, 30 lignes de code, c'est pas la mort... Et est-ce que ça vaut le coup de rajouter une dépendance pour ça ?

[laupt]

Merci pour vos avis.

En fait, queue.h est juste un header avec une liste de macros. Cela n'inclut pas de dépendances, et n'est pas dépendant de l'OS non plus (hormis bien sûr le chemin où le trouver qui dépend de sa distrib... mais bon, il suffit de le copier ailleurs!).

Je comprends vos points de vue, je pense avoir trouvé un juste milieu entre tout réécrire, et être dépendant d'une librairie, ou d'un système...