Discussion :

[_kal_]

Bien garder en tête que ident ne doit pas être un pointeur (ou alors déréférencé : *p, voire multiplié par une nombre d'éléments : *p * n, enfin, ça dépend des cas, bref, c'est pas évident). Je préfère la méthode du void *...

Tout à fait, sinon l'utilisation de l'opérateur "." serait illégal. Je n'ai pas eu l'occasion d'étudier la forme avec des pointeurs génériques, mais elle semble être moins difficile à mettre en œuvre (je trouve l'écriture de macros moins lisible, question de gouts...)

[tintin72]

Ceci dit je n'arrive pas bien à saisir comment utiliser une liste avec le pointeur void*.
Dans le main de l'exemple
http://nicolasj.developpez.com/articles/listesimple/
la valeur des éléments est passé via un tableau (2 dim) de char

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
char text[][6] = { "Hello", " ", "World", "!" };
 
for (i = 0; i < 4; i++)
{
  sll_insert (p_sll, text[i]);
}

ce qui voudrait dire que si je veux stoker des int dans ma liste il faut d'abord que je déclare une variable int (ou un tableau de int) , que je lui affecte une valeur, puis qu'ensuite je procède à l'insertion ?
Je ne vois pas trop l'intérêt s'il faut à chaque fois déclarer une variable pour chaque élément.
Pour une liste générique je verrais plutôt une insertion du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
sll_insert (p_sll, 24); //ajoute un élément dans la liste et y stocke la valeur 24

plus dans l'esprit STL.
Mais bon, je n'ai peut être pas bien compris l'utilisation du pointeur générique.

[Emmanuel Delahaye]

Ceci dit je n'arrive pas bien à saisir comment utiliser une liste avec le pointeur void*.
<...>Mais bon, je n'ai peut être pas bien compris l'utilisation du pointeur générique.

Le pointeur contient l'adresse des données de l'utilisateur. C'est tout. Le mécanisme de gestion de la liste ne s'occupe jamais des données elle-même (il n'en a strictement rien à faire). Il se contente de stocker l'adresse et de la retourner si nécessaire.

L'utilisateur est complètement responsables de la mémoire des données (après tout, ce sont les siennes...) et de leur persistance (durée de vie).

Autre avantage, dans le mécanisme de gestion de la liste, les données ne sont jamais recopiées.

http://emmanuel-delahaye.developpez.com/clib.htm
Module GLL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
struct node
{
   struct node *p_next;
   struct node *p_prev;
   void const *p_data;
};

[David.Schris]

Le pointeur contient l'adresse des données de l'utilisateur. C'est tout. Le mécanisme de gestion de la liste ne s'occupe jamais des données elle-meêm (il n'en a strictement rien à faire). Il se contente de stocker l'adresse et de la retourner si nécessaire.

[...]

Autre avantage, dans le mécanisme de gestion de la liste, les données ne sont jamais recopiées.

[...]

Encore un autre avantage : cela permet de créer des listes qui contiennent (chacune) des données de types (et tailles) différents (i.e. : on peut enfin mélanger les torchons et les serviettes ). A utiliser avec parcimonie...

[Emmanuel Delahaye]

Encore un autre avantage : cela permet de créer des listes qui contiennent (chacune) des données de types (et tailles) différents (i.e. : on peut enfin mélanger les torchons et les serviettes ). A utiliser avec parcimonie...

Structures avec selecteur (ou union) recommandées.

[LLB]

Encore un autre avantage : cela permet de créer des listes qui contiennent (chacune) des données de types (et tailles) différents.

Oui, mais c'est un défaut en même temps.
Ca affaiblit le système de typage (déjà qu'il est pas très fort à la base), et empêche la détection de nombreuses erreurs à la compilation. Ca demande donc une plus grande rigueur.

L'autre problème soulevé par tintin, c'est si l'on veut manipuler un type simple (genre les entiers), on doit systématiquement passer par des variables.

Je préfère donc éviter tant que possible de passer par le void*, et je conseillerais plutôt de passer par des macros (mais c'est sûrement aussi une question).

[Emmanuel Delahaye]

Oui, mais c'est un défaut en même temps.
Ca affaiblit le système de typage (déjà qu'il est pas très fort à la base), et empêche la détection de nombreuses erreurs à la compilation. Ca demande donc une plus grande rigueur.

C'est sûr, le C , "c'est pas un langage de tapettes"... (humour!)

[David.Schris]

Oui, mais c'est un défaut en même temps.
Ca affaiblit le système de typage (déjà qu'il est pas très fort à la base), et empêche la détection de nombreuses erreurs à la compilation. Ca demande donc une plus grande rigueur.

L'autre problème soulevé par tintin, c'est si l'on veut manipuler un type simple (genre les entiers), on doit systématiquement passer par des variables.

Je préfère donc éviter tant que possible de passer par le void*, et je conseillerais plutôt de passer par des macros (mais c'est sûrement aussi une question).

C'est sûr, le C , "c'est pas un langage de tapettes"... (humour!)

@ED :

@LLB :
"Oui, mais c'est un défaut en même temps." => pas si c'est un besoin.

"Ca demande donc une plus grande rigueur." => oui, d'où "A utiliser avec parcimonie..." dans mon message.

"L'autre problème soulevé par tintin, c'est si l'on veut manipuler un type simple (genre les entiers), on doit systématiquement passer par des variables." => si par "passer par des variables" tu veux dire "déclarer une variable par élément de liste", alors : non, ce n'est pas systématiquement nécessaire (mais implique alors de créer une copie des valeurs insérées/ajoutées).

"mais c'est sûrement aussi une question" => de goût, un peu...de besoin, surtout.

"Ca affaiblit le système de typage (déjà qu'il est pas très fort à la base), et empêche la détection de nombreuses erreurs à la compilation." => oui et non.
Imagines que tu aies une librairie de liste générique (avec une fonction "BOOL ajouterAListe(t_MonSuperTypeListe l, void *elementAAjouter);").
Tu vas écrire un programme qui va créer des listes avec des trucs de type A et d'autres de type B dans la même liste.
Dans ce cas, la première chose à faire, si cela n'a pas déjà été fait dans la librairie (typiquement pour tous les types de base cela devrait être déjà fait), est de créer des fonctions qui serviront d'interface pour les types A et B ("BOOL ajouter_A_AListe(t_MonSuperTypeListe l, A elementDeTypeA);" et "BOOL ajouter_B_AListe(t_MonSuperTypeListe l, B elementDeTypeB);").
Ensuite tu peux écrire ton programme sans JAMAIS appeler la fonction générique mais en appelant toujours les fonctions qui servent d'interface.
Maintenant, essayes de déclarer une variable V de type A et d'écrire "retour = ajouter_B_AListe(l, V);"...si ton compilateur ne râle pas parce que le type est mauvais : changes-en.
Enfin si la création de ces fonctions-interfaces paraît rebutante, il y a moyen d'alléger un peu les choses en créant une macro pour en simplifier l'écriture...

J'ai pas dit de bêtise ? Je peux aller me coucher ?

[Pikwik]

Oui, mais c'est un défaut en même temps.
Ca affaiblit le système de typage (déjà qu'il est pas très fort à la base), et empêche la détection de nombreuses erreurs à la compilation. Ca demande donc une plus grande rigueur.

D'où l'interet de créer un "manager" avec des fonctions qui s'occupe du typage pour l'enregistrement et la récupération des donnèes.

[johnnyjohnny]

Essaye avec queue.h (tu le chopes dans les sources d'un unix libre genre netbsd).

Ca te permet de créer toute sorte de listes et d'opérations dessus. Tu définis ta structure et ça marche.