Discussion :

[Amnael]

Je bute sur cette erreur depuis des heures et je ne comprends pas d'où elle peut bien venir...

Voici la fonction

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
File transfertGRDversFile(GRD a,File f)
{
	if(!estVideGRD(a))
	{
		transfertGRDversFile(a->gauche,f);
		enfiler(&f,f.debut,a->val);
		transfertGRDversFile(a->droite,f);
	}
	return f;
}

error: dereferencing pointer to incomplete type
J'obtiens cette erreur sur chaque paramètre partant de mon arbre. a->gauche a->droite a->val


Je tiens à préciser que la fonction enfiler avait bien été testé et elle fonctionne correctement.

Code :

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

int enfiler (File * suite, Element * courant, int donnee);

Ici ce que je veux faire c'est envoyer dans une file les entiers de mon arbre.


Au paravant, j'avais une fonction de type void qui affichait un arbre sur le même principe et qui fonctionnait comme il faut, j'ai donc simplement repris la même structure en remplaçant l'affichage par le fait d'enfiler l'entier dans ma file que je retourne à la fin.

Code :

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

1
2
3
4
5
6
7
8
9
void triGRD(GRD a)
{
	if(!estVideGRD(a))
	{
		triGRD(a->gauche);
		printf("%d\n",a->val);
		triGRD(a->droite);
	}
}

J ne vois vraiment pas d'où provient l'erreur ni à quoi elle est du

Need help

Cdlt, Merci.


EDIT: Je rajoute les structures on sait jamais =)

Arbre

Code :

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

1
2
3
4
5
6
7
typedef struct unfeuille {
	int val;
	struct unfeuille *gauche;
	struct unfeuille *droite;
}feuille;
 
typedef struct unfeuille * GRD;

File

Code :

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

1
2
3
4
5
6
7
8
9
10
typedef struct ElementListe{
  int donnee;
  struct ElementListe *suivant;
} Element;
 
typedef struct ListeRepere{
  Element *debut;
  Element *fin;
  int taille;
} File;

[Obsidian]

Bonjour,

Cacher un pointeur dans un typedef (lors de la définition de GRD) est une mauvaise pratique, même si elle se fait beaucoup à l'école.
À part cela, quel compilateur utilises-tu ? Ça fonctionne avec une version récente de GCC.

« error: dereferencing pointer to incomplete type » signifie que tu essaies d'accéder aux membres d'un type qui n'a pas encore été totalement défini. C'est utile par exemple lorsque l'on veut définir deux structures distinctes A et B qui se référencent mutuellement (avec un pointeur). Comme il faut bien déclarer l'une avant l'autre, on déclare les noms de structures avec « struct A; struct B; » mais sans définir le contenu de ces structures. Ça nous permet ensuite de les définir pleinement avec :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
struct A
{
    B * pointeur_vers_b;
    …
};
 
struct B
{
    A * pointeur_vers_a;
    …
};

Il se peut que tu aies oublié d'inclure les headers définissant pleinement ces structures en tête du code source dans lequel se produit l'erreur.

[Amnael]

J'utilise Gcc avec la plupart des options possible; on avait créer un alias en tp et j'ai jamais supprimé. Je trouve que c'ets mieux comme ça, ça force à plus de rigueur.

Dans le fichier où la dite fonction est présente, j'utilise les en-tête suivante

Code :

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

1
2
3
4
5
6
7
8
9
10
#include "file_statique.h"
#include "arbre.h"
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
 
la fonction
 
 
le main

file_statique.h

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
#ifndef ___FILLE_STATIQUE___
#define ___FILLE_STATIQUE___
 
/* FirstInFirstOut */
#define file_donnee(suite) suite->debut->donnee
 
typedef struct ElementListe{
  int donnee;
  struct ElementListe *suivant;
} Element;
 
typedef struct ListeRepere{
  Element *debut;
  Element *fin;
  int taille;
} File;
 
/* initialisation */
void initialisation (File * suite);
 
/* ENFILER*/
int enfiler (File * suite, Element * courant, int donnee);
 
/* DE_FILER*/
int de_filer (File * suite);
 
/* Affiche la file */
void affiche(File *suite);
 
#endif

Et dans arbre.h

Code :

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

typedef struct unfeuille * GRD;

arbre.c

Code :

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

1
2
3
4
5
typedef struct unfeuille {
	int val;
	struct unfeuille *gauche;
	struct unfeuille *droite;
}feuille;

En fait la structure de base de GRD est "caché" dans le .c auquel le main n'a pas accès; et donc c'est la source de l'erreur ? Donc je prend cette erreur à cause de ma protection de structure sur l'arbre ?

C'est un peu con...

Il n'y aurait pas moyen "d'inclure" le .c pour que ça passe au compilo ?

[Amnael]

C'était bien vu, en envoyant la structure d'arbre.c dans arbre.h ça a marché.

Mais du coup maintenant j'ai une autre question

Si j'avais voulu garder ma protection de structure est ce que je n'aurais pas pu m'en sortir quand même ?

[Obsidian]

Si j'avais voulu garder ma protection de structure est ce que je n'aurais pas pu m'en sortir quand même ?

Nos derniers commentaires se sont croisés.

Comme dit dans le précédent, donc, c'est à toi d'être au clair sur ce que tu veux réellement faire à la base, le reste devrait venir naturellement derrière. Si tu veux entièrement protéger ton type, tu peux commencer par placer sa déclaration dans un fichier *.h distinct, qui ne sera inclus que par les routines de gestion de ton objet. Ensuite, il faudra que tu mettes à disposition du public un ensemble de facilités pour exploiter ton objet, sinon il ne servira à rien.

[Obsidian]

En fait la structure de base de GRD est "caché" dans le .c auquel le main n'a pas accès; et donc c'est la source de l'erreur ? Donc je prend cette erreur à cause de ma protection de structure sur l'arbre ?

Oui.

C'est un peu con... Il n'y aurait pas moyen "d'inclure" le .c pour que ça passe au compilo ?

En fait, ici, ton erreur n'est pas technique mais conceptuelle : tu souhaites que GRD soit un type opaque MAIS tu veux quand même accéder à ses membres depuis ton programme principal ! Si ceux-ci sont publics, alors leur déclaration doit l'être aussi. Dans le cas contraire, il faut utiliser des accesseurs.

[Sve@r]

Il n'y aurait pas moyen "d'inclure" le .c pour que ça passe au compilo ?

Bonjour
On n'inclut jamais un .c dans un .h (de même qu'on n'écrit pas de code dans un .h) pour plusieurs raisons

• le .h est destiné au public (qui aura ainsi le prototype des fonctions utilisées) tandis que le code peut être secret/protégé. Mettre ton code dans un vecteur public empêche cette protection
• si le .h est inclut dans différents sources du projet, ton code dupliqué peut alors provoquer une collision lors de la compil
• de toute façon vu qu'il est toujours possible de ne pas le faire ; ca montre une erreur de conception

Et sinon comme cela a été dit, on ne masque jamais un pointeur dans un typedef. C'est une habitude qu'adoptent les profs de C pour essayer de "laisser de coté" les pointeurs et éviter de les expliquer (les comprennent-ils eux-mêmes parfois on se le demande) mais malheureusement pour eux (et pour leurs élèves), le pointeur est un élément incontournable du C. Or le masquer a tendance à le faire oublier alors qu'il est primordial de toujours connaitre les pointeurs qu'on manipule pour justement bien les manipuler...

[Amnael]

Merci pour vos réponses à tous les deux, c'est un peu plus clair désormais; même si je ne pense pas avoir la totalité du bagage à disposition encore =)


Lorsque vous dites

Et sinon comme cela a été dit, on ne masque jamais un pointeur dans un typedef

Vous parlez par exemple de la ligne ou je fais un typedef struct unfeuille* GRD ?


C'est vrai que dans tous les tuto que je lis, je ne vois jamais ce type de redéfinition; et au lieu d'avoir GRD on aurait eu unfeuille**


Si c'est bien de cela que vous parler, je trouve ça aussi plus logique de ne pas faire ça, mais dans les cours ça fait aussi parti de la notation; au final je dirais que ça donne un sens plus clair au code pour quelqun qui le relirait derrière nous.

Je pense que c’est pas mauvais du moment qu'on est conscient que c'est un pointeur qui se cache derrière.

[Sve@r]

C'est vrai que dans tous les tuto que je lis, je ne vois jamais ce type de redéfinition; et au lieu d'avoir GRD on aurait eu unfeuille**

Exact. Etant donné que la feuille d'un arbre est un pointeur, modifier ce pointeur dans une fonction implique que la fonction reçoive l'adresse de cette feuille, autrement dit un "feuille **"

C'est pour éviter ce cas qu'il est courant de définir aussi une structure pour l'arbre lui-même

Exemple

Code c :

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

1
2
3
4
5
6
7
8
9
typedef struct s_feuille {
	int val;
	struct s_feuille *gauche;
	struct s_feuille *droite;
}t_feuille;
 
typedef struct {
	t_feuille *racine;
} t_arbre;

Ainsi, une fonction recevant comme paramètre l'adresse de cet arbre (un t_arbre *arbre) pourra sans souci accéder et modifier la racine (arbre->racine=...). Bref on rajoute un élément intermédiaire entre les deux étoiles de ce ** qui t'embête.
Ce qui ouvre aussi d'autres possibilités. Comme par exemple rajouter des infos sur l'arbre lui-même comme par exemple sa profondeur maximale, le nb de ses éléments, etc. Ainsi toute fonction recevant cet arbre aura immédiatement accès à tous ces paramètres. Bref c'est un premier pas vers le "tout objet"...

Accessoirement tu remarqueras que nommer ses structures "s_xxx" et ses types "t_xxx" renforce aussi la lisibilité du code tout en gardant le token "arbre" disponible pour un nom de variable.

Je pense que c’est pas mauvais du moment qu'on est conscient que c'est un pointeur qui se cache derrière.

Tu comprendras quand tu reviendras sur un de tes codes six mois après...

[Obsidian]

Merci pour vos réponses à tous les deux, c'est un peu plus clair désormais; même si je ne pense pas avoir la totalité du bagage à disposition encore =)

Même sans bagage, tu peux quand même te pencher sur ceci :

• Tu veux que ton type soit opaque ;
• Ton programme appelle quand même a->gauche, a->droite et a->val.

En principe, tu n'es même pas censé savoir qu'il existe des membres qui s'appellent « gauche », « droite » et « val ». Tu ne le sais que parce que c'est toi qui a écrit l'objet. :-)

Vous parlez par exemple de la ligne ou je fais un typedef struct unfeuille* GRD ?

Oui.

Si c'est bien de cela que vous parler, je trouve ça aussi plus logique de ne pas faire ça, mais dans les cours ça fait aussi parti de la notation; au final je dirais que ça donne un sens plus clair au code pour quelqun qui le relirait derrière nous.

Il y a beaucoup de professeurs qui font cela parce qu'il est très fréquent, en école d'informatique, d'apprendre d'emblée les rudiments du C et ceux de l'algorithmique. Ça a l'air d'être une manière simple de dissocier les deux mais en réalité, on se fait tout de suite rattraper par les contraintes que l'on a voulu contourner. Ne serait-ce que parce qu'il faut quand même utiliser les bonnes conventions d'appel (par exemple, « -> »).