Discussion :

[Magicien d'Oz]

Petit problème : un même programme bête de TP sur les pointeurs fonctionne à merveille compilé avec GCC sous une Debian mais produit un résultat horrible avec une compilation par Dev C++ via ming je ne sais quoi.

J'utilise juste les bibs : stdio.h et stdlib.h

Ya t-il à adapter quoi que ce soit, changer le nom d'une lib, en rajouter une pour rendre le programme correct sous windows ? Quelle est ma bêtise grossière que je connais pas ?

Voilà le listing complet en brut...

et merci pour votre aide bien sûr !

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
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
 
#include<stdio.h> /* pour la declaration de NULL */
#include<stdlib.h>
 
struct cellule
{int nb;
  struct cellule *suivant;
};
 
struct t_file
{
  struct cellule *premier;
  struct cellule *dernier;
};
 
 
void initialiser(struct t_file *f)
{
  f->premier=NULL;
  f->dernier=NULL;
 
}
 
void inserer(struct t_file *f , int valeur)
{
  /* Cas premier element */
  if ((f->premier == NULL) && (f->dernier == NULL) )
    {
      f->dernier=(struct cellule *) malloc (sizeof(struct cellule));
      f->dernier->nb=valeur;
      f->dernier->suivant=NULL;
      f->premier=f->dernier;
    }
  else
    {
      f->dernier->suivant = (struct cellule *) malloc (sizeof(struct cellule));
      f->dernier->suivant->nb = valeur;
      f->dernier=f->dernier->suivant;
    }
}
 
 
void afficher(struct t_file f)
{
  struct cellule *temp;
  temp = f.premier;
 
  while (temp != NULL)
    {
      printf("%d \n", temp->nb);
      temp=temp->suivant;
    }
}
 
int compter(struct t_file f)
{
    int compteur =0;
    struct cellule *temp;
    temp = f.premier;
    while (temp != NULL)
    {
          compteur =compteur +1;
      temp=temp->suivant;
    }
    return compteur;
}
 
 
 
void afficher_debut(struct t_file f)
{
  if (f.premier != NULL)
    {
      printf("%d \n", f.premier->nb);
    }
}
 
void afficher_fin(struct t_file f)
{
  if (f.dernier != NULL)
    {
      printf("%d \n", f.dernier->nb);
    }
}
 
 
void supprimer(struct t_file *f)
 
{
  f->premier = f->premier->suivant;
 
}
 
 
 
int main (void)
{
 
  struct t_file f;
  initialiser (&f);
  inserer (&f,3);
  inserer(&f,5);
  afficher(f);
  afficher_debut(f);
  afficher_fin(f);
  supprimer(&f);
  afficher(f);
  printf("%d \n",compter(f));
 
  return 0;
}

[Médinoc]

Tu as des erreurs de compilation, ou seulement à l'exécution?
On peut avoir tes options et les erreurs?

[Magicien d'Oz]

merci pour la balise faut que je m'y fasse...

en fait la compilation passe toute seule, je clique juste sur le bouton compiler de Dev C++. Mais à l'exécution, j'ai une suite ininterrompue de chiffres dans les 4016544, comme si j'allais fouiller quelque part où il faudrait pas. Je comprends pas car sous Linux, ça m'affiche juste ce que je veux...

D'autres renseignements ?

PS : en plus précis voilà mon exécution

3
5
4016496
3998072
4016496
3998072
4016496
3998072
4016496
3998072
4016496
3998072
4016496
3998072

et la suite continue

[Médinoc]

1°) est ton ami

2°) En fait, je me poserais plutôt des questions sur le passage de structures entières en paramètres... Est-ce que tu as le même bug en passant un pointeur constant à la place?

3°) Une belle fuite de mémoire dans la fonction supprimer, qui de plus ne met pas dernier à NULL quand on supprime le dernier, et génèrera une segfault si on tente de supprimer dans le vide.

< LAST BUT NOT LEAST : Voilà la source de tes ennuis >
4°) Quand tu insères une nouvelle structure et qu'il y en a déjà une, son pointeur suivant n'est pas initilisé à NULL --> la file continue dans le vide.
Sous nux, tu avais peut-être la chance d'avoir la mémoire allouée initialisée à zéro, mais ce n'est pas défini par le standard (c'est un malloc(), pas un calloc())

[Marcin]

Code :

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

1
2
3
4
5
6
 
<...>
      f->dernier=(struct cellule *) malloc (sizeof(struct cellule));
<...>
      f->dernier->suivant = (struct cellule *) malloc (sizeof(struct cellule));
<...>

Quand tu alloues de la mémoire pour tes structures, utilises calloc(). Ca initialisera les éléments de la structure à 0 ou NULL (selon le type). Malloc() ne le fait pas, ce qui fait que lors de l'affichage ta boucle while ne s'arrête jamais (pas de NULL final).

[Emmanuel Delahaye]

Petit problème : un même programme bête de TP sur les pointeurs fonctionne à merveille compilé avec GCC sous une Debian mais produit un résultat horrible avec une compilation par Dev C++ via ming je ne sais quoi.

C'est sûremement de la faute du compilateur...

J'utilise juste les bibs : stdio.h et stdlib.h

Eeek! Des fichiers d'entête (et il manque les <>). Les libs (bibliothèques) ce sont des .lib, .a etc. que tu ajoutes au projet.

Ya t-il à adapter quoi que ce soit, changer le nom d'une lib, en rajouter une pour rendre le programme correct sous windows ? Quelle est ma bêtise grossière que je connais pas ?

Probablement un comportement indéfini...

La compilation a l'air correcte, mais j'ai une belle boucle infinie...

En fait, il manque un NULL au pointeur 'suivant' du nouvel élement. Pour éviter ce genre d'oubli, on sépare la création/initialisation de la structure et sa mise en liste :

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
20
21
22
23
24
void inserer (struct t_file *f, int valeur)
{
   /* -ed- creation de l'element */
   struct cellule *new = malloc (sizeof *new);
   if (new != NULL)
   {
      new->nb = valeur;
      new->suivant = NULL;
 
      /* -ed- gestion des liens */
 
      /* Cas premier element */
      if (f->premier == NULL && f->dernier == NULL)
      {
         f->premier = new;
         f->dernier = f->premier;
      }
      else
      {
         f->dernier->suivant = new;
         f->dernier = f->dernier->suivant;
      }
   }
}

quand à la liberation, il faut veiller à ne pas couper la branche sur laquele on est assis...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
void supprimer (struct t_file *f)
{
   /* -ed- a liberer */
   struct cellule *old =f->premier;
 
   f->premier = f->premier->suivant;
 
   /* -ed- liberation. */
   free (old), old=NULL;
}

Enfin, je ne fais pas de passe de structures par valeurs. J'utilise T*p ou T const *p selon les besoins.

[Magicien d'Oz]

Ouah, voilà de la réponse. Je te remercie beaucoup, je dors et demain j'essaie à tête reposée. Ca devrait marcher, merci beaucoup.

Médinoc est notre maître, saluons Médinoc...

PS : edit j'adore, tu peux corriger tes fautes !

PPS : ah on m'a encore écrit pour m'aider, ouaaahhh....
merci à tous, surtout pour les précisions lib fichiers d'en tête...

[Magicien d'Oz]

Bon ben c'est fini, j'ai mis calloc à la place et ça marche. Donc merci encore pour les éclairements.[/b]

[Emmanuel Delahaye]

Bon ben c'est fini, j'ai mis calloc à la place et ça marche. Donc merci encore pour les éclairements.

C'est la solution de facilité, mais elle n'est pas portable. Il y a des architectures où 'tous les bits d'un pointeur à 0' ne signifie pas NULL. J'ai proposé une solution plus industrielle.

[Magicien d'Oz]

il y a des architectures où le langage C n'est pas le même... Je me disais bien que y avait une bonne raison pour que je préfère l'ADA !
Merci quand même, c'est sympa de voir plusieurs méthodes.

une dernière question ed : je comprends ce que tu proposes mais à la création pourquoi le test "if (new != NULL)" ?

[Pouic]

pourquoi le test "if (new != NULL)" ?

Il faut bien vérifier que la fonction malloc n'a pas échouée....

[Emmanuel Delahaye]

il y a des architectures où le langage C n'est pas le même...

En l'occurence, non. Il y a des architectures différentes sur laquelle le langage C est le même. La sémantique de NULL est inchangée, mais il ne faut pas la court-circuiter. Il faut utiliser les abstractions que définient le langage.

Code :

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

T *p = NULL

ou

Code :

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

T *p = 0;

ont une sémantique garantie par le langage.
Celle de

Code :

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

1
2
T*p;
memset (&p, sizeof p, 0);

n'est pas garantie comme équivallente à

Code :

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

T *p = NULL;

C'est tout. Il faut le savoir et utiliser les bons éléments du langages.

Je me disais bien que y avait une bonne raison pour que je préfère l'ADA !

Je ne sais pas si Ada (c'est un patronyme, comme Pascal et non un acronyme comme BASIC) est aussi portable que le C, mais il est certain que sur des architectures particulières, NULL, NIL (ou son équivallent en Ada) ne vaut pas 'tous les bits à 0'. Ce n'est pas une question de langage, mais d'architecture. Par contre, il est possible que le niveau d'abstraction d'Ada interdise les manips de bas niveau 'à-la-C' comme le memset().

Merci quand même, c'est sympa de voir plusieurs méthodes.

Certaines sont portables, d'autres non...

une dernière question ed : je comprends ce que tu proposes mais à la création pourquoi le test "if (new != NULL)" ?

malloc() peut échouer. Toujours et partout.

[Pouic]

Par contre, il est possible que le niveau d'abstraction d'Ada interdise les manips de bas niveau 'à-la-C' comme le memset().

Détrompe-toi, on peut même définir des champs de bits, et les manipuler comme en C ;-) (et plus fort, on peut se permettre d'avoir le même code pour manipuler les bits que l'on soit en big ou little endian... Un bonheur )

[Emmanuel Delahaye]

Par contre, il est possible que le niveau d'abstraction d'Ada interdise les manips de bas niveau 'à-la-C' comme le memset().

Détrompe-toi, on peut même définir des champs de bits, et les manipuler comme en C ;-) (et plus fort, on peut se permettre d'avoir le même code pour manipuler les bits que l'on soit en big ou little endian... Un bonheur )

Sur un entier non signé, oui, bien sûr, mais pas sur un pointeur quand même ? Ou alors Ada n'est pas si solide qu'on le prétend...

[jobherzt]

salut !
j'ai un probleme un peu similaire, que j'ai poste dans la rubrique c++. disons que je penses que la source de mon erreur est du meme ordre (je suis un habitue de ce genre de conneries :-) ) mais la il me semble avoir fait gaffe ce coup ci, a bien foutre des NULL de partout. comme je ne veux pas faire de double post, mais que je vois qu'il y a ici des gens qui reperent ce genre de pb d'un seul coup d'oeil ( ce qu'on n'obtiendrais pas par la flatterie .. ), je vous mets un lien :

http://www.developpez.net/forums/viewtopic.php?t=406234

en esperant que ca ne depasse pas les regles de bienseances propres a ce charmant forum.

En vous remerciant !

[Emmanuel Delahaye]

e vous mets un lien :

http://www.developpez.net/forums/viewtopic.php?t=406234

en esperant que ca ne depasse pas les regles de bienseances propres a ce charmant forum.

Si c'est du code C, oui. Si c'est du C++, comme je ne connais pas, je ne regarde pas.

[jobherzt]

objectivement, c'est du c++ puisque c'est une classe. mais enfin ca reste une file, et ca reste (vraisemblablement ) un probleme bete de pointeur. (notamment, en plus ( a cause ? ) de ce truc qui merdouille, je pense avoir une bonne fuite de memoire, mais comme ce truc merdouille, justement, que je laisse passer des pointeurs "anormaux", je n'arrive pas a les liberer proprement.

enfin bref, en soi c'est du c++ mais l'erreur provient de notions communes aux 2 langages. donc a toi de voir ....

[Emmanuel Delahaye]

objectivement, c'est du c++

Affaire reglée.