Flot et surprise

Version imprimable

Flot et surprise

Bonjour,
Je ne comprends pas pourquoi l'ouverture d'un flot perturbe l'affichage de ma "fiche".
Un résumé avant le code complet :
Fiche est une structure composée de 3 char[] (nom,prenom,tel).
Je crée une Fiche fiche1, je demande de l'afficher. Aucun problème.
Puis j'ouvre un flot. Et sans rien faire de plus (en tout cas rien de volontaire). Quand je fais afficher ma fiche, le prenom a ... disparu !!

Merci d'avance.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
#define TNOM 64
#define TTEL 10
#define MAXFICHES 10
 
typedef struct Fiche *Fiche;
struct Fiche {
    char nom[TNOM];
    char prenom[TNOM];
    char tel[TTEL];
};
 
typedef Fiche AnnuaireT[MAXFICHES];
 
Fiche newFiche(char * nom, char * prenom, char *tel)
{
  Fiche fiche=(Fiche) calloc(1,sizeof(Fiche));
  if (fiche==NULL)
  {
  	printf("Pb Calloc");
  	exit(0);
  }
  strcpy(fiche->nom,nom);
	strcpy(fiche->prenom,prenom);
	strcpy(fiche->tel,tel);
 
  return fiche;
}
 
 
char * lireLigne(char *dst,size_t taille,FILE *flot){
  int i;
  if(fgets(dst,taille,flot)==NULL)
    {printf("Dans lireLigne \n");return NULL;}
  /* Enlever l'éventuel \n */
  i = strlen(dst)-1;
  if (i <= 0)
    {printf("Un seulchar \n");return NULL;}
  if( dst[i] == '\n')
    dst[i] = '\0';
  return dst;
}
 
Fiche lireFiche(FILE * flot)
{
  char nom[TNOM], prenom[TNOM],tel[TTEL];
  Fiche fiche;
 
  if (lireLigne(nom,TNOM,flot) == NULL) /* fin atteinte */
    return NULL;
 
  lireLigne(prenom,TNOM,flot);
 
  lireLigne(tel,TTEL+1,flot);
  fiche = newFiche(nom,prenom,tel);
  return fiche;
}
 
int lireTout(const char * source, AnnuaireT cible)
{
  FILE * flot;
  int i=0;
 
  flot = fopen(source,"r"); /* ouverture en lecture */
  if (flot == NULL) {
    perror("erreur ouverture fichier");
    return 0;
  }
 
  do {
    cible[i] = lireFiche(flot);
    printf("coucoup %d vrai ? %d\n",i,(cible[i]==NULL));
    i++;
  }
  while ( (i<MAXFICHES) && (cible[i-1] != NULL) );
 
  fclose(flot);
 
  if (cible[i-1] == NULL) {
      return i-1;
  } else {
    return MAXFICHES;
  }
}
 
void afFiche(Fiche f)
{
  printf("%s\n%s\n%10s\n",f->nom,f->prenom,f->tel);
}
 
void afficheAnnuaireT(AnnuaireT a)
{
  int i=0;
 
  while ( (i < MAXFICHES) && (a[i] != NULL) )
    {
      afFiche(a[i]);
      i++;
    }   
  printf("\n");
}
 
int sauverFiche(Fiche fiche, FILE * flot)
{
  int ret=0;
 
  if (fiche != NULL)
    ret=fprintf(flot,"%s\n%s\n%10s\n",
                fiche->nom,
                fiche->prenom,
                fiche->tel);
  return ret;
}
 
int main(void)
{
	int i;
	AnnuaireT myAnnuaire;
	Fiche fiche1=newFiche("AUBRAC","Lucie","1111111111");
	FILE *perso;
 
	for(i=0;i<MAXFICHES;i++)
		myAnnuaire[i]=NULL;
	myAnnuaire[0]=fiche1;
 
	/*perso=fopen("Test1.txt","w");
	if (perso == NULL) {
    perror("erreur ouverture fichier");
    return 0;
  }//*/
 
	afficheAnnuaireT(myAnnuaire);
 
	//fclose(perso);
 
	return EXIT_FAILURE;
}

12/04/2012, 10h31
diogene

Ceci est faux :

Code:

Fiche fiche=(Fiche) calloc(1,sizeof(Fiche));

Fiche est un pointeur sur struct Fiche, donc ceci alloue la taille d'un pointeur, pas d'une struct Fiche. Ce type d'erreur vient sans doute de la mauvaise idée de cacher un pointeur dans un typedef. De plus le choix des identificateurs struct Fiche et Fiche pour désigner deux choses radicalement différentes est source de confusion.

Code:

Fiche fiche= calloc(1,sizeof *fiche);
12/04/2012, 11h59
ChatPo

Bonjour,
Notez que ce matin, je n'ai plus ce problème.
J'ai modifié mon typedef (il s'appellera ptrFiche).
Merci.
(Si le pb se reproduit, je redémarre l'ordi)

Bonjour,
le même problème est revenu (malgré un redémarrage de l'ordi)
Voila tout le code :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
/* MonFichier.c */
 
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
#define TNOM 64
#define TTEL 10
#define MAXFICHES 100
 
typedef struct Fiche *ptrFiche;
struct Fiche {
    char nom[TNOM];
    char prenom[TNOM];
    char tel[TTEL];
};
 
typedef ptrFiche AnnuaireT [MAXFICHES];
 
ptrFiche newFiche(char * nom, char * prenom, char *tel);
char * lireLigne(char *dst,size_t taille,FILE *flot);
ptrFiche lireFiche(FILE * flot);
int lireTout(const char * source, AnnuaireT cible);
void afFiche(ptrFiche f);
void afficheAnnuaireT(AnnuaireT a);
int sauverFiche(ptrFiche fiche, FILE * flot);
ptrFiche saisirFiche(void);
int sauverTout(AnnuaireT source, const char * cible);
 
 
ptrFiche newFiche(char * nom, char * prenom, char *tel)
{
  ptrFiche fiche=(ptrFiche) calloc(1,sizeof(ptrFiche));
  if (fiche==NULL)
  {
  	printf("Pb Calloc");
  	exit(0);
  }
  strcpy(fiche->nom,nom);
  strcpy(fiche->prenom,prenom);
  strcpy(fiche->tel,tel);
 
  return fiche;
}
 
 
char * lireLigne(char *dst,size_t taille,FILE *flot)
{
  int i;
  if(fgets(dst,taille,flot)==NULL)
    {return NULL;}
  /* Enlever l'éventuel \n */
  if (strlen(dst)==taille-1)
    {i = taille;fgetc(flot);}
  else
    i=strlen(dst)-1;
  if (i <= 0)
    {return NULL;}
  if( dst[i] == '\n')
    dst[i] = '\0';
  return dst;
}
 
ptrFiche lireFiche(FILE * flot)
{
  char nom[TNOM], prenom[TNOM],tel[TTEL];
  ptrFiche fiche;
  if (lireLigne(nom,TNOM,flot) == NULL) /* fin atteinte */
    return NULL;
  lireLigne(prenom,TNOM,flot);
  lireLigne(tel,TTEL+1,flot);
  fiche = newFiche(nom,prenom,tel);
  return fiche;
}
 
int lireTout(const char * source, AnnuaireT cible)
{
  FILE * flot;
  int i=0;
 
  flot = fopen(source,"r"); /* ouverture en lecture */
  if (flot == NULL) {
    perror("erreur ouverture fichier");
    return 0;
  }
 
  do {
    cible[i] = lireFiche(flot);
    i++;
  }
  while ( (i<MAXFICHES) && (cible[i-1] != NULL) );
 
  fclose(flot);
 
  if (cible[i-1] == NULL) {
      return i-1;
  } else {
    return MAXFICHES;
  }
}
 
void afFiche(ptrFiche f)
{
  printf("%s\n%s\n%10s\n",f->nom,f->prenom,f->tel);
}
 
void afficheAnnuaireT(AnnuaireT a)
{
  int i=0;
 
  while ( (i < MAXFICHES) && (a[i] != NULL) )
    {
      afFiche(a[i]);
      i++;
    }   
  printf("\n");
}
 
int sauverFiche(ptrFiche fiche, FILE * flot)
{
  int ret=0;
 
  if (fiche != NULL)
    ret=fprintf(flot,"%s\n%s\n%10s\n",
                fiche->nom,
                fiche->prenom,
                fiche->tel);
  return ret;
}
 
ptrFiche saisirFiche(void)
{
  return lireFiche(stdin);
}
 
int sauverTout(AnnuaireT source, const char * cible)
{
  int i;
  FILE * flot;
 
  flot = fopen(cible,"w"); /* ouverture en écriture */
  if (flot == NULL)
    {
      perror("erreur ouverture fichier");
      exit(EXIT_FAILURE);
    }
 
  for(i=0;i<MAXFICHES;i++)
    sauverFiche(source[i], flot);
 
  fclose(flot);
 
  return 0;
}
 
 
int main(int argc,char *argv[])
{
 
	int i,choix=1,fin,choixChamp;
	char fichier[100],nomInd[TNOM],tempo[7],nouvChamp[TNOM];
	AnnuaireT myAnnuaire;
	ptrFiche fiche1=newFiche("AUBE","Crepuscule","00");
	FILE *perso,*nouveau;
 
	for(i=0;i<MAXFICHES;i++)
		myAnnuaire[i]=NULL;
 
	if (argc==1)
	{
		strcpy(fichier,"Test.txt");
	}
	else
	{
		strcpy(fichier,argv[1]);
	}	
	printf("L'annuaire choisi est dans le fichier %s\n",fichier);
	printf("****MENU****\n");
	printf("\t 1 : Charger un fichier\n");
	printf("\t 2 : Sauver\n");
	printf("\t 3 : Sauver sous un autre nom\n");
	printf("\t 4 : Ajouter une fiche\n");
	printf("\t 5 : Rechercher une fiche par le nom\n");
	printf("\t 6 : Modifier une fiche\n");
	printf("\t 7 : Afficher l'annuaire\n");
	printf("\t 0 : Quitter\n");
	printf("\t\t Votre choix :");
 
	perso=fopen(fichier,"r");
	if (perso == NULL) 
	{
	  perror("erreur ouverture fichier");
	  return 0;
	}
 
	myAnnuaire[0]=fiche1;
	afficheAnnuaireT(myAnnuaire);
 
	fclose(perso);
 
	return EXIT_FAILURE;
}

Je ne comprends rien.

Merci d'avance.

12/04/2012, 20h43
gerald3d

Sans régler le problème l'écriture suivante pose un gros problème pour la lecture du code et sa compréhension. C'est donc à éviter :

Code:

typedef struct Fiche *ptrFiche;

Puisque tu ajoutes "ptr" au nom de ta structure il me semble que le signe "*" parle de lui-même.
13/04/2012, 05h29
denispir
Citation:

Envoyé par gerald3d

Sans régler le problème l'écriture suivante pose un gros problème pour la lecture du code et sa compréhension. C'est donc à éviter :

Code:

typedef struct Fiche *ptrFiche;

Puisque tu ajoutes "ptr" au nom de ta structure il me semble que le signe "*" parle de lui-même.

Est-ce que tu (Gérald) pourrais élaborer cette réponse? Je ne comprends pas bien ce que tu évoques là. Est-ce que tu veux dire que "* ptrFiche" devrait signifier et se lire (ailleurs dans le code, loin de la définition du typedef) "pointeur sur un pointeur de fiche"?

J'ai le même genre de problème assez couramment en C (et dans tous les langages avec pointage explicite), je ne sais pas comment définir et nommer des éléments (et leurs types) qui doivent (souvent pas systématiquement) être passés ou traités par référence (mais parfois aussi par valeur, les mêmes éléments). Ca m'emm*** grave. Les confusions et erreurs que tu évoques dans le message précédent me semblent inévitables, ou alors je n'ai moi pas encore trouvé la solution (ou en tout cas une solution qui convienne à ma façon de penser).
Le seul cas où ça va bien est celui de noeuds dans une structure structurellement récursive genre liste chaînée ou arbre. Là, contrairement à ton avis si je le comprends bien, je définis systématiquement le type comme une référence implicite, genre:
Code:

1 2 3 4 5 6 typedef struct NodeData { int item ; struct NodeData * next; } * Node ;
Et je sais tout au long du prog (du fait de la signification et de la récursivité intrinsèque de la structure) qu'il ne peut s'agir que d'éléments accédés par référence. Mais ça ne me satisfait pas complètement (et je n'ai pas trouvé mieux dans du code lu d'autrui).

Denis

Ceci est faux et toujours pour la même raison :

Code:

ptrFiche fiche=(ptrFiche) calloc(1,sizeof(ptrFiche));

On doit avoir
Code:

1 2 3 ptrFiche fiche = calloc(1,sizeof *fiche); // ou ce qui est équivalent : ptrFiche fiche = calloc(1,sizeof (struct Fiche));
Note accessoire :
Personnellement (mais c'est une question de goût) je préférerais avoir les définitions :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 typedef struct { char nom[TNOM]; char prenom[TNOM]; char tel[TTEL]; }Fiche; Fiche * newFiche(char * nom, char * prenom, char *tel) { Fiche * fiche = calloc(1,sizeof *fiche); // ou Fiche * fiche = calloc(1,sizeof (Fiche)); ....
où les pointeurs sont explicitements indiqués dans le code.

13/04/2012, 10h53
gerald3d
Citation:
Envoyé par denispir

Est-ce que tu (Gérald) pourrais élaborer cette réponse? Je ne comprends pas bien ce que tu évoques là. Est-ce que tu veux dire que "* ptrFiche" devrait signifier et se lire (ailleurs dans le code, loin de la définition du typedef) "pointeur sur un pointeur de fiche"?

J'ai le même genre de problème assez couramment en C (et dans tous les langages avec pointage explicite), je ne sais pas comment définir et nommer des éléments (et leurs types) qui doivent (souvent pas systématiquement) être passés ou traités par référence (mais parfois aussi par valeur, les mêmes éléments). Ca m'emm*** grave. Les confusions et erreurs que tu évoques dans le message précédent me semblent inévitables, ou alors je n'ai moi pas encore trouvé la solution (ou en tout cas une solution qui convienne à ma façon de penser).
Le seul cas où ça va bien est celui de noeuds dans une structure structurellement récursive genre liste chaînée ou arbre. Là, contrairement à ton avis si je le comprends bien, je définis systématiquement le type comme une référence implicite, genre:

Code:

1 2 3 4 5 6 typedef struct NodeData { int item ; struct NodeData * next; } * Node ;

Et je sais tout au long du prog (du fait de la signification et de la récursivité intrinsèque de la structure) qu'il ne peut s'agir que d'éléments accédés par référence. Mais ça ne me satisfait pas complètement (et je n'ai pas trouvé mieux dans du code lu d'autrui).

Denis
L'utilisation des pointeurs est généralement la partie la plus difficile à comprendre en C. Le programmeur DOIT toujours savoir ce qu'il manipule. Pour se faire il lui suffit en principe de regarder si c'est une variable, un pointeur sur une variable, une adresse d'un pointeur... Pour permettre cette lecture le signe "*" est prépondérant.

Maintenant lorsqu'on déclare un nouveau type en intégrant dans sa déclaration le signe "*" la lecture devient très rapidement difficile. Si je déclare typedef struct Fiche *ptrFiche; je vais rapidement me retrouver dans mon programme à me poser la question de savoir si je manipule une variable, son pointeur ou autre.
Il est FORTEMENT conseillé de déclarer un type de variable et non un type sur un pointeur de variable.
J'écris donc plutôt :

Code:

typedef struct Fiche fiche;

Ainsi lorsque je déclare par exemple fiche mafiche; je sais que je viens de déclarer une variable. Si je veux ensuite accéder à son pointeur il me suffira d'ajouter "*". La lecture devient claire.

Voila où je voulais en venir ;)

Citation:

Envoyé par gerald3d

L'utilisation des pointeurs est généralement la partie la plus difficile à comprendre en C. Le programmeur DOIT toujours savoir ce qu'il manipule. Pour se faire il lui suffit en principe de regarder si c'est une variable, un pointeur sur une variable, une adresse d'un pointeur... Pour permettre cette lecture le signe "*" est prépondérant.

Maintenant lorsqu'on déclare un nouveau type en intégrant dans sa déclaration le signe "*" la lecture devient très rapidement difficile. Si je déclare typedef struct Fiche *ptrFiche; je vais rapidement me retrouver dans mon programme à me poser la question de savoir si je manipule une variable, son pointeur ou autre.
Il est FORTEMENT conseillé de déclarer un type de variable et non un type sur un pointeur de variable.
J'écris donc plutôt :

Code:

typedef struct Fiche fiche;

Ainsi lorsque je déclare par exemple fiche mafiche; je sais que je viens de déclarer une variable. Si je veux ensuite accéder à son pointeur il me suffira d'ajouter "*". La lecture devient claire.

Voila où je voulais en venir ;)

D'accord, si je comprends bien, ça veut dire que toutes les définitions de types (dont typedefs) sont faites sur des données accédées directement, par valeurs. Ensuite, à la création d'éléments de ces types il n'y a pas de '*', tandis qu'à la création de pointeurs sur ces éléments le type porte un '*'. Jusque là tout va bien pour moi. Cela surcharge un peu le code, mais en fait cette surcharge est porteuse d'information, et je suis à fond pour cela.
Le problème est dans l'usage ultérieur des variables de différents types, par valeur ou par référence. Si je fais par exemple:
Code:

1 2 3 4 5 6 7 Fiche * newFiche = malloc (1 * size(Fiche)) Fiche * nextFiche = malloc (1 * size(Fiche)) [...] newFiche.next = nextFiche ; // (1) newFiche->next = &nextFiche ; // (2) newFiche.next = &nextFiche ; // (0)
J'ai une erreur en (1) car j'ai "oublié" que newfiche est déjà "pointé", et en 2 même chose pour nextFiche; (0) est incorrect pour ces 2 raisons à la fois. Bref, ici il y a une chance sur 4. A moins d'avoir une pratique systématique et bien documentée dans le code. Le problème est que d'expérience, il y a des des types de données qui doivent être accédées par référence, d'autres par valeur directement, et surtout des mêmes types de données qui doivent être éccédés parfois par valeur parfois par référence. Donc la stratégie systématique est perdante d'avance, même en essayant de classifier à priori les "types de types" de données. Par exemple, certaines collections genre tableau dynamique devront être par valeur ou par référence suivant ce qu'ils représentent (et même pour la même donnée suivant l'opération exécutée dessus).

Comment savoir sur quoi on opère, alors, un fois "oubliée" la déclaration? (N'oublions pas que le lecteur du code ne vient pas nécessairement de taper la déclaration 5 min avant. On peut être en phase de test, de maintenance, de refactoring...) Il faudrait alors coder les noms de variable. Aïe! c'est lourd, c'est laid, c'est difficile à lire pour quiconque ne connaît pas ton codage ou n'y est pas pleinement habitué, etc...
Code:

1 2 3 4 5 Fiche * p_newFiche = malloc (1 * size(Fiche)) Fiche * p_nextFiche = malloc (1 * size(Fiche)) [...] p_newFiche->next = p_nextFiche ; // (3)
(3) est correct (je crois, j'ai pas testé ;-) et pleinement explicite; en fait sans doute correct du pemier coup parce que pleinement explicite. S'il faut en passer par là, je le ferai, mais franchement ce genre de code ne me plaît pas du tout.
Et dans le cas de noeuds d'une structure chaînée et récursive (ex un arbre binaire), /tous/ les éléments ne peuvent être /que/ pointés. Donc, moi, dans ce cas là, si j'applique ce genre de style de codage pleinement explicite j'ai vraiment l'impression d'être un idiot qui tape et lit des '*' et ' p_' partout, alors que sémantiquement, pour ainsi dire par nature, toutes ces variables-là ne peuvent être /que/ des références.

Alors peut-être qu'une solution est d'être pleinement explicite dans le cas général; sauf lorsque la nature sémantique des éléments impose elle-même une interprétation des variables et de leurs données. Avec un bout de doc, du genre:
Code:

1 2 3 4 5 6 7 8 /* [...] Due to their meaning, nodes can only be accessed by reference. Thus in code both their type name typedef NodeDate * Node ; and variable names like in Node node = malloc (sizeof NodeData) ; are implicite about their beeing pointers. */
(Voilà où j'en suis de mes réflexions sur ce problème.)

Denis

PS: L'exemple donnée par Dogène sans le fil http://www.developpez.net/forums/d12...er-parametres/ est particulièrement parlant pour moi. 2 params sur 3 sont par ref, et ensuite dans les formules (voir le code) il doit déréférencer ces 2 là mais pas le troisième. Hum...

Citation:

Envoyé par gerald3d

L'utilisation des pointeurs est généralement la partie la plus difficile à comprendre en C. Le programmeur DOIT toujours savoir ce qu'il manipule. Pour se faire il lui suffit en principe de regarder si c'est une variable, un pointeur sur une variable, une adresse d'un pointeur... Pour permettre cette lecture le signe "*" est prépondérant.

Salut,

je ne suis pas entièrement d'accord. Le programmeur NE DOIT PAS TOUJOURS savoir ce qu'il manipule, mais il doit TOUJOURS avoir des fonctions qui lui permettent de manipuler :)
Je m'explique :
Dans le cas où le programmeur utilise une bibliothèque, celle-ci aura avantage à lui fournir des services par pointeur opaque, cela permet d'une part d'éviter que le programmeur trifouille dans la SDD et y fasse des choses non prévues, et d'autre part cela rend la bibliothèque plus robuste car en cas de gros changement les programmes qui l'utilisent n'ont pas à être recompilés si l'interface (le ou les .h en général) ne change pas.

Par exemple si on doit fournir une liste, l'interface pourra être :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 /* List.h */ typedef struct liste_t* Liste; void l_creer(Liste* liste); void l_detruire(Liste* liste); int l_ajouter_tete(Liste liste, int valeur); int l_ajouter_queue(Liste liste, int valeur); int l_supprimer_tete(Liste liste, int* valeur); int l_supprimer_queue(Liste liste, int* valeur); int l_contient(Liste liste, int valeur); ....
Ici on a jamais à se poser la question si on doit écrire l-> ou l. car on ne doit pas (enfin peut pas) l'écrire. On sait que c'est un pointeur et ça suffit.
La bibliothèque (au sens large, une bibliothèque dynamique dll/so ou une statique lib/a ou un simple fichier objet) peut changer l'implémentation de la liste en passant d'une liste simplement chainée à un autre type de sdd sans pour autant que le programme qui l'utilise ait besoin de modifications, ni même de recompilation en cas de bibliothèque dynamique.

Citation:
Envoyé par kwariz
Salut,

je ne suis pas entièrement d'accord. Le programmeur NE DOIT PAS TOUJOURS savoir ce qu'il manipule, mais il doit TOUJOURS avoir des fonctions qui lui permettent de manipuler :)
Je m'explique :
Dans le cas où le programmeur utilise une bibliothèque, celle-ci aura avantage à lui fournir des services par pointeur opaque, cela permet d'une part d'éviter que le programmeur trifouille dans la SDD et y fasse des choses non prévues, et d'autre part cela rend la bibliothèque plus robuste car en cas de gros changement les programmes qui l'utilisent n'ont pas à être recompilés si l'interface (le ou les .h en général) ne change pas.

Par exemple si on doit fournir une liste, l'interface pourra être :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 /* List.h */ typedef struct liste_t* Liste; void l_creer(Liste* liste); void l_detruire(Liste* liste); int l_ajouter_tete(Liste liste, int valeur); int l_ajouter_queue(Liste liste, int valeur); int l_supprimer_tete(Liste liste, int* valeur); int l_supprimer_queue(Liste liste, int* valeur); int l_contient(Liste liste, int valeur); ....
Ici on a jamais à se poser la question si on doit écrire l-> ou l. car on ne doit pas (enfin peut pas) l'écrire. On sait que c'est un pointeur et ça suffit.
La bibliothèque (au sens large, une bibliothèque dynamique dll/so ou une statique lib/a ou un simple fichier objet) peut changer l'implémentation de la liste en passant d'une liste simplement chainée à un autre type de sdd sans pour autant que le programme qui l'utilise ait besoin de modifications, ni même de recompilation en cas de bibliothèque dynamique.
Intéressant et éclairant, merci kwariz.

Est-ce que dans ton code il y a une erreur, ou est-ce moi qui ne comprends pas le pointage (*) de l'élément 'liste' dans les 2 méthodes 'créer' et 'détruire' (alors que son type Liste est déjà celui d'un pointeur)? Est-ce que tu fais là une double indirection intentionnellement? si oui pourquoi (si c pas une typo, j'ai un peu dans l'idée que cela pourrait contribuer à l'étanchéité de l'interface, mais je saisis pas bien comment).

denis

13/04/2012, 23h41
kwariz

Citation:

Envoyé par denispir

Intéressant et éclairant, merci kwariz.

Est-ce que dans ton code il y a une erreur, ou est-ce moi qui ne comprends pas le pointage (*) de l'élément 'liste' dans les 2 méthodes 'créer' et 'détruire' (alors que son type Liste est déjà celui d'un pointeur)? Est-ce que tu fais là une double indirection intentionnellement? si oui pourquoi (si c pas une typo, j'ai un peu dans l'idée que cela pourrait contribuer à l'étanchéité de l'interface, mais je saisis pas bien comment).

denis

En fait cela vient principalement du destructeur. On utilise un pointeur sur liste pour pouvoir, après la libération mémoire et autre clean up, l'initialiser à NULL. Pour garder une cohérence d'écriture le constructeur suit le même prototypage (une version fonction reste possible évidemment, juste une question de style). On peut également utiliser des pointeurs avec les autres fonctions (uniformité des prototypes), du coup on se rapproche un peu plus de l'objet car finalement (en gros) une méthode d'objet n'est qu'une fonction ayant pour paramètre un pointeur nommé this ...
14/04/2012, 08h03
denispir
Citation:

Envoyé par kwariz

En fait cela vient principalement du destructeur. On utilise un pointeur sur liste pour pouvoir, après la libération mémoire et autre clean up, l'initialiser à NULL. Pour garder une cohérence d'écriture le constructeur suit le même prototypage (une version fonction reste possible évidemment, juste une question de style). On peut également utiliser des pointeurs avec les autres fonctions (uniformité des prototypes), du coup on se rapproche un peu plus de l'objet car finalement (en gros) une méthode d'objet n'est qu'une fonction ayant pour paramètre un pointeur nommé this ...

D'accord. Quel est l'intérêt d'annuler ce pointeur? Je veux dire, il n'existe que parce que ton interface l'exige (n'est pas dû à la nécessité d'alloc sur le tas) et ne pointe que sur un pointeur, si j comprends bien.

Imaginons que l'élément liste proprement dite ne soit pas en fait (un pointeur sur) la première cellule mais une struct du genre (comme je fais souvent, ce qui entre autres permet l'ajout en fin de liste en O(1)):
Code:

1 2 3 4 5 6 struct Liste { size_t count ; Cell * first ; Cell * last ; } ;
Dans ce cas, tu aurais également un constructeur et un destructeur avec paramètre List*, j'imagine (mais cette fois simplement pointé)? Et les autres "méthodes"?

Denis

PS: J'en profite pour remercier cheleureusement les participants réguliers à ce forum très intéressant. J'apprends beaucoup, ça me fait réfléchir, et (comme dans le cas présent) pas seulement sur C.
14/04/2012, 10h56
diogene
Ce qui est néfaste, à mon avis, c'est de masquer un pointeur sur l'objet qui représente l'information que l'on veut manipuler.
Ainsi, lorsque kwariz écrit typedef struct liste_t* Liste, il ne masque pas un pointeur : la liste est elle-même représentée par un pointeur.

Je préfèrerais toutefois avoir quelque chose qui distingue radicalement la liste de ses cellules, du genre :
Code:

1 2 3 4 5 typedef struct liste_t Cell; typedef struct { Cell * first ; } Liste ;
Le code associé pourrait être
Code:

1 2 3 4 5 6 7 void l_init(Liste* liste) // au lieu de l_creer : cette fonction ne fait qu'initialiser une liste { liste->first = NULL; // liste vide } .... Liste list; l_init(&list);
Si la définition de Liste est modifiée avec
Code:

1 2 3 4 5 6 typedef struct { size_t count ; Cell * first ; Cell * last ; } Liste ;
Le code des fonctions manipulant la liste est à modifier, par exemple :
Code:

1 2 3 4 5 void l_init(Liste* liste) // au lieu de l_creer : cette fonction ne fait qu'initialiser une liste { liste->count = 0; // liste vide liste->first = liste->last = NULL; }
mais si le programme n'utilise pour accéder à la liste que ces fonctions, il reste inchangé. On a toujours
Code:

1 2 Liste list; l_init(&list);
Par contre, et logiquement, puisque la liste doit être modifiée, on aura des fonctions avec
Code:

1 2 3 int l_ajouter_tete(Liste *liste, int valeur); int l_ajouter_queue(Liste *liste, int valeur); ....
et par souci d'homogenéité et pour éviter la recopie de la structure

Code:

int l_contient(Liste const *liste, int valeur);

Si on veut vraiment créer une liste par allocation dynamique (et toujours avec une fonction void, ce qui n'est pas le plus astucieux) , on aura, indépendamment de la définition de la Liste
Code:

1 2 3 4 5 6 7 8 9 10 11 void l_creer(Liste** liste) { if(liste != NULL) { Liste * p = malloc(sizeof *p); if(p != NULL) l_init(p); *liste = p; } } Liste * pliste; l_creer(&pliste);
mais ceci est plus naturel :
Code:

1 2 3 4 5 6 7 Liste* l_creer(void) { Liste * p = malloc(sizeof *p); if(p != NULL) l_init(p); return p; } Liste * pliste = l_creer();

Citation:
Envoyé par kwariz
Salut,

je ne suis pas entièrement d'accord. Le programmeur NE DOIT PAS TOUJOURS savoir ce qu'il manipule, mais il doit TOUJOURS avoir des fonctions qui lui permettent de manipuler :)
Je m'explique :
Dans le cas où le programmeur utilise une bibliothèque, celle-ci aura avantage à lui fournir des services par pointeur opaque, cela permet d'une part d'éviter que le programmeur trifouille dans la SDD et y fasse des choses non prévues, et d'autre part cela rend la bibliothèque plus robuste car en cas de gros changement les programmes qui l'utilisent n'ont pas à être recompilés si l'interface (le ou les .h en général) ne change pas.

Par exemple si on doit fournir une liste, l'interface pourra être :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 /* List.h */ typedef struct liste_t* Liste; void l_creer(Liste* liste); void l_detruire(Liste* liste); int l_ajouter_tete(Liste liste, int valeur); int l_ajouter_queue(Liste liste, int valeur); int l_supprimer_tete(Liste liste, int* valeur); int l_supprimer_queue(Liste liste, int* valeur); int l_contient(Liste liste, int valeur); ....
Ici on a jamais à se poser la question si on doit écrire l-> ou l. car on ne doit pas (enfin peut pas) l'écrire. On sait que c'est un pointeur et ça suffit.
La bibliothèque (au sens large, une bibliothèque dynamique dll/so ou une statique lib/a ou un simple fichier objet) peut changer l'implémentation de la liste en passant d'une liste simplement chainée à un autre type de sdd sans pour autant que le programme qui l'utilise ait besoin de modifications, ni même de recompilation en cas de bibliothèque dynamique.
Oui, pourquoi pas. Je crois qu'on touche aux habitudes de programmation. J'aime bien savoir ce que je manipule. D'où ma réponse peut être un peu trop directive ;).

14/04/2012, 12h51
kwariz
En fait quand je proposais un :
Code:

1 2 typedef struct liste_t* Liste
je proposais cela dans le cadre du développement d'une bibliothèque : il s'agit d'une forward declaration. Liste est bel et bien un pointeur cachant les détails d'implémentation de la liste. La bibliothèque pourra très bien avoir implémenté un
Code:

1 2 3 4 5 6 struct liste { int count; int capacity; int* list; };
pour utiliser une représentation sous forme de tableau d'entier dynamiquement extensible ou un
Code:

1 2 3 4 5 6 7 struct liste { int load_factor; int balance_constant; double memory_threshold; AVL_tree_hash_list athl; };
qui peut être le résultat du croisement d'une idée de Knuth et de Ullman tiré d'un papier trouvé sur citeseerx ... (je raconte n'importe quoi là :), ce n'est qu'un exemple inventé).

L'utilisateur de la bibliothèque se moque de connaître l'implémentation réelle, lui il dispose d'un pointeur et de fonctions qui font le boulot : une boîte noire parfaite.

Ensuite le fait de passer passer des pointeurs sur Liste (donc des pointeurs sur pointeurs de struct) ou non à des fonctions est relativement secondaire ; sauf que c'est évidemment nécessaire pour toutes les fonctions modifiant l'adresse de l'objet pointé (construction a minima si implémentée comme procédure). Mais le fait de choisir entre
- void l_create(Liste*,...) / void l_destroy(Liste*)
  pour mimer une approche objet
  le destroy permettant de mettre la liste pointée à NULL (les autres fonctions savent quoi faire si on leur repasse par erreur une Liste NULL) -> peut cacher des erreurs de conception
- Liste l_alloc(...) / void l_free(Liste)
  pour mimer malloc/free
  après un l_free, Liste est différent NULL ; ce n'est pas grave, mais si tu réutilises ce pointeur rien n'indique qu'il a été libéré (tout comme free) -> peut amener des plantages suite à des erreurs de conception
- toute autre idée adaptée
est fait au niveau du design de l'interface et reste conceptuel. L'important est d'en choisir une et de s'y tenir.L'utilisateur de la bibliothèque doit savoir que s'il a besoin d'une ressource il l'acquiert avec un template identique pour chaque ressource. Il faut rester cohérent dans son design.

Citation:

Envoyé par diogene

Ce qui est néfaste, à mon avis, c'est de masquer un pointeur sur l'objet qui représente l'information que l'on veut manipuler.
Ainsi, lorsque kwariz écrit typedef struct liste_t* Liste, il ne masque pas un pointeur : la liste est elle-même représentée par un pointeur.

Ah, je comprends mieux maintenant. En fait, la liste = pointeur sur noeud est ici vraiment à considérer comme un objet liste...
Citation:
Je préfèrerais toutefois avoir quelque chose qui distingue radicalement la liste de ses cellules, du genre :
Code:

1 2 3 4 5 typedef struct liste_t Cell; typedef struct { Cell * first ; } Liste ;
Le code associé pourrait être
Code:

1 2 3 4 5 6 7 void l_init(Liste* liste) // au lieu de l_creer : cette fonction ne fait qu'initialiser une liste { liste->first = NULL; // liste vide } .... Liste list; l_init(&list);
.. qui est mieux concrétisé (si on peut dire ;-) dans un cas comme celui-ci. Je préfère cent fois cette solution-ci (par opp à celle de la prog fonctionnelle) qui en plus permet d'ajouter des champs (comme compte ou dernier) qui à la fois clarifient, facilitent et rendent plus efficace l'implantation. Mais --il y a un mais-- cette distinction liste / pointeur sur noeud interdit le style PF de prog récursive qui a néanmoins son intérêt (et son élégance, et sa difficulté d'abstraction), du genre:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 typedef struct Cellule_t Cellule ; typedef Cellule Liste ; struct Cellule_t { int element ; Cellule * next ; } ; bool contains (Liste * l, int valeur) { if (l == NULL) return false ; // ci-dessous simple récursion return ((l->element == valeur) || contains (l->next, valeur)) ; }
Ce genre de code implique qu'une liste en en fait un pointeur de noeud, et réciproquement; du coup, ->next peut être traité comme une sous-liste ce qui permet la récursivité "descendante". (C'est aussi très proche de la fascinante notion d'auto-similarité, voire wikipedia).
Citation:
Si la définition de Liste est modifiée avec
Code:

1 2 3 4 5 6 typedef struct { size_t count ; Cell * first ; Cell * last ; } Liste ;
Le code des fonctions manipulant la liste est à modifier, par exemple :
Code:

1 2 3 4 5 void l_init(Liste* liste) // au lieu de l_creer : cette fonction ne fait qu'initialiser une liste { liste->count = 0; // liste vide liste->first = liste->last = NULL; }
mais si le programme n'utilise pour accéder à la liste que ces fonctions, il reste inchangé. On a toujours
Code:

1 2 Liste list; l_init(&list);
Oui, très intéressant, merci. Du fait de mon passé avec des langs dynamiques, j'ai tendance à oublier les bienfaits du masquage de l'implantation.
Citation:
Par contre, et logiquement, puisque la liste doit être modifiée, on aura des fonctions avec
Code:

1 2 3 int l_ajouter_tete(Liste *liste, int valeur); int l_ajouter_queue(Liste *liste, int valeur); ....
et par souci d'homogenéité et pour éviter la recopie de la structure

Code:

int l_contient(Liste const *liste, int valeur);
D'ac, là je comprends bien, je crois, à la fois l'évitement de la copie et l'homogénéité. Homogénéité avec les fonctions qui doivent recevoir un pointeur sur la liste car elles sont susceptibles de la modifier: c'est bien ça?
Citation:
Si on veut vraiment créer une liste par allocation dynamique (et toujours avec une fonction void, ce qui n'est pas le plus astucieux) , on aura, indépendamment de la définition de la Liste
Code:

1 2 3 4 5 6 7 8 9 10 11 void l_creer(Liste** liste) { if(liste != NULL) { Liste * p = malloc(sizeof *p); if(p != NULL) l_init(p); *liste = p; } } Liste * pliste; l_creer(&pliste);
mais ceci est plus naturel :
Code:

1 2 3 4 5 6 7 Liste* l_creer(void) { Liste * p = malloc(sizeof *p); if(p != NULL) l_init(p); return p; } Liste * pliste = l_creer();
Oui, cette version est bien meilleure et plus claire. J'aime bien aussi ta manière (plus haut) de créer et initialiser la liste indépendamment (de cette manière-là émane une drôle de douceur, je trouve; ???).

Denis

Citation:

Mais --il y a un mais-- cette distinction liste / pointeur sur noeud interdit le style PF de prog récursive qui a néanmoins son intérêt (et son élégance, et sa difficulté d'abstraction), du genre: ...

Cela ne l'interdit pas mais demande un codage à double étage pour encapsuler la fonction récursive.
Code:

1 2 3 4 5 6 7 8 9 static bool inlist(Cell const * cell, int valeur) { ....// appel récursif à inlist() } bool contains (Liste const * l, int valeur) { if (l == NULL) return false ; return inlist(l->first, valeur); }
Il ne faut pas non plus vanter à l'excès les constructions récursives, malgré leur élégance, à cause des pénalités à payer (rapidité, occupation de la pile) à l'exécution.

Citation:
Envoyé par diogene
Cela ne l'interdit pas mais demande un codage à double étage pour encapsuler la fonction récursive.
Code:

1 2 3 4 5 6 7 8 9 static bool inlist(Cell const * cell, int valeur) { ....// appel récursif à inlist() } bool contains (Liste const * l, int valeur) { if (l == NULL) return false ; return inlist(l->first, valeur); }
Il ne faut pas non plus vanter à l'excès les constructions récursives, malgré leur élégance, à cause des pénalités à payer (rapidité, occupation de la pile) à l'exécution.
Oui, tu as raison, diogène.

Denis

15/04/2012, 14h33
denispir

à ChatPo

Ce serait bien que tu nous montres les différentes sorties terminal que tu obtiens, en indiquant bien pour chacune la ou les versions de code ou situations dans lesquelles tu les constates.

Aussi, ton problème me fait penser à perturbations de flux de sortie que j'ai pu constater (dans d'autres langgaes, mais implantés eux en C). Ca vient parfois de l'absence de flush (vidage de tampon) par défaut dans certaines instructions d'écriture sur une sortie, en C. Parfois dans le dialogue et avec les couches logicielles, ça met un peu de foutoir. Mais en général le problème est plutôt que l'on obtient bien tout, mais dans le désordre.
Ca m'arrive assez fréquemment lorsque j'exécute de l'intérieur de mon editeur favori (geany, écrit en C++), dans son teminal virtual. Entres autres, les messages de compil sont presque toujours dans le désordre (et dans differents ordres). Du fait qu'il n'y a pas de flush Il peut y a avoir plusieur flux de sortie en // sur le même terminal (ceux de geany, du compilateur du "relieur"); et aussi geany fait peut-être du threading.

Voilà, je ne sais pas si ces problèmes-là ont un lien avec le tien (tu ne nous donnes pas assez de billes). Je ne donne ces infos un peu vagues que parce que ta question est en suspens depuis quelques temps, apparemment sans piste de solution.

denis