Discussion :

[Mike888]

Hello !

P'tite question sur la désallocation de mémoire :


J'ai une liste (doublement chainée, mais peu importe) dont chaque cellule contient un pointeur sur void.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
typedef struct scell
{
  void * value;
  struct scell * next, * previous;
}
cell;
 
 
typedef struct slist
{
  int nbcell;
  cell * first, * current, * last;
}
list;

Ce pointeur sur void va en fait pointer sur deux structures différentes (une destinée aux competitions et l'autre aux concurrents). Je mets pour l'exemple celle des competitions :

Code :

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

1
2
3
4
5
6
7
struct competition
{
  char matric[3], intitule[36], datedeb[9], pays[4];
  int tabinscp[100];
  int flagcompet;
  int poscp;
};

Au cours de mon programme j'ai donc alloué de la mémoire pour ces structures.
Ex :

Code :

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

1
2
struct competition * p_compet;
p_compet = malloc( sizeof( struct competition ) );

Et cela autant de fois qu'il y a de compétitons (idem pour les concurrents)

J'ai également chaque fois créé une nouvelle celleule dans ma liste afin de "contenir" la structure compétition sus-créée.

Code :

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

1
2
3
4
5
6
7
8
9
{
    lis->current = lis->last->previous;
    lis->current->next->previous = ( cell * ) malloc( sizeof( cell ) );
    lis->current->next->previous->value = x;
    lis->current->next->previous->previous = lis->current;
    lis->current->next->previous->next = lis->current->next;
    lis->current->next = lis->current->next->previous;
    ( lis->nbcell ) ++;
  }

Voilà !...
Bon, maintenant, j'en suis à la libération de toutes ces structures (fin de programme). Est-ce qu'un free d'une cellule va automatiquement engendrer un free d'une structure (je ne pense pas mais je voudrais une confirmation) ?

Merci !

[fearyourself]

Bon, maintenant, j'en suis à la libération de toutes ces structures (fin de programme). Est-ce qu'un free d'une cellule va automatiquement engendrer un free d'une structure (je ne pense pas mais je voudrais une confirmation) ?

Effecivement, il va falloir mettre un free pour la structure.

Quelques remarques:

Code :

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

   lis->current->next->previous = ( cell * ) malloc( sizeof( cell ) );

Un test pour vérifier que le malloc a réussi serait bien

Ce pointeur sur void va en fait pointer sur deux structures différentes (une destinée aux competitions et l'autre aux concurrents)

Pourquoi ne pas utiliser une union?

Jc

[Mike888]

Pourquoi ne pas utiliser une union?

C-à-d ?

[fearyourself]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
typedef union sdata
{
  struct competition *compet;
  struct concurrent *concur;
}data;
 
//Type de données
#define AUCUN 0
#define COMPET 1
#define CONCUR 2
 
typedef struct scell
{
  data value;
  int type;
  struct scell * next, * previous;
}
cell;

Avantages:
- Le code est plus lisible et plus "gérable", on teste le type pour savoir quel est la nature
de la cellule, il n'y a plus d'erreur possible de pointeur (confondre un pointeur competiton avec un pointeur concurrent)

- Il n'y aura plus de pointeur void*, c'est donc mieux car ça provoque souvent des erreurs

Inconvénients:

- C'est un peu plus long à coder car tu as une union

- La variable type utilise un peu plus de mémoire mais tu pourrais le mettre en short, ou si tu sais qu'il n'y a pas de confusion, tu pourrais l'enlever carrément. Bien qu'à ce moment là, le seul avantage à l'utilisation d'une union réside à ne plus avoir de pointeur void, ce qui n'est pas forcément négligeable.


Jc

EDITION: C'est sûrement une affaire de goût... Quoique la plupart des gens sont d'accord pour éviter les pointeurs void...

[Mike888]

Euh oui, ça a l'air pas mal ... mais là je suis sur la fin de mon projet donc je vais pas tout changer

Merci quand meme

[Emmanuel Delahaye]

Quoique la plupart des gens sont d'accord pour éviter les pointeurs void...

Quand tu fais du code générique tu n'as pas le choix.

[ciol2.6.12]

on peut remplacer void * par un type par ex. liste_t dans un liste.h :
typedef type que l'on veut liste_t;
si on change de type il y a juste un mot à changer, l'anvantage c'est de ne pas tout recoder à chaque fois et d'éviter les casts.

[Emmanuel Delahaye]

on peut remplacer void * par un type par ex. liste_t dans un liste.h :
typedef type que l'on veut liste_t;
si on change de type il y a juste un mot à changer, l'anvantage c'est de ne pas tout recoder à chaque fois et d'éviter les casts.

Pas de cast en C. void * est compatible avec tous les types pointeurs sur objets (et inversement).

Le code générique est utilisé tel quel sans modification. C'est l'utilisateur qui connait ses données. (voir qsort() et sa fonction de comparaison).

Il peut ajouter une surcouche d'interface si il veut...

[ciol2.6.12]

Pas de cast en C. void * est compatible avec tous les types pointeurs sur objets (et inversement).

ah bon.
Pourtant :

Code :

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

1
2
3
4
5
6
7
 
void fonction()
{
     int m;
     void *p = &m;
     *p = 2;  /* code correct :  *(int *)p = 2; */
}

ne compile pas.

[Médinoc]

Mais:

Code :

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

1
2
3
4
5
6
7
void fonction()
{
     int m;
     void *p = &m;
     int *pi = p;
     *pi = 2;
}

Compile parfaitement.
et pire:

Code :

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

1
2
3
4
5
6
7
void fonction()
{
     float f;
     void *p = &f;
     int *pi = p;
     *pi = 2;
}

Compile aussi.