Discussion :

[latitude38]

Bonjour,

Dans le code que j'utilise, j'ai plusieurs variables globales, dont un tableaux de type int TAB[2][n].

Définis dans l'un des fichiers file1.c, j'aimerais m'en servir dans un autre fichier file2.c.
J'ai donc créé un fichier Entete.h destiné à être inclus dans file2.c.

Quelle forme aura ma déclaration de référence dans Entente.h ?
Celle-ci ne semble pas convenir au compilateur :

Code :

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

1
2
 
extern int TAB[2][n];

Faut il passer par le pointeur comme ceci ?

Code :

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

1
2
 
extern int* TAB;

Merci de votre aide.

[Invité]

C'est normal que cela ne lui plaise pas. Et il râle à juste raison !

Tu lui dis qu'il existe quelque part une variable, qui est un tableau de taille variable.
Comment tu veux que, pauvre petit compilateur qu'il est, puisse savoir qu'elle sera la taille de ce tableau, et jusque dans quel mesure il pourra l'utiliser ?

Le soucis avec ton tableau à taille dynamique, là, c'est que tu ne pourras le lui faire avaler.

Soit tu lui donnes une adresse fixe, soit tu es dans l'obligation d'utiliser un pointeur. L'avantage du pointeur est qu'il te permet justement de masquer cette partie dynamique.
Par contre, il faut du coup faire beaucoup plus attention dans son utilisation. C'est moins "parlant" qu'un tableau.

Je dirais que d'une manière générale, essaye d'éviter ce style d'écriture, même si cela fait partie de la norme C99. Cela amène beaucoup d'embrouille pour un avantage somme-toute assez réduit (je trouve, personnellement).

Quand à la manière de présenter la chose...

Si tu es courageux: extern int *montableau Mais tu devras alors gérer manuellement chaque niveau de ton tableau.
Sinon, pour paraphraser ce que j'ai pu lire ici : "Une étoile par dimension supplémentaire" pour un tableau, donc extern int **montableau dans ton cas. (mais je m'attends à ce que l'on me reprenne sur cette affirmation.)

[diogene]

...
Soit tu lui donnes une adresse fixe, soit tu es dans l'obligation d'utiliser un pointeur. L'avantage du pointeur est qu'il te permet justement de masquer cette partie dynamique.
Par contre, il faut du coup faire beaucoup plus attention dans son utilisation. C'est moins "parlant" qu'un tableau.

Ce n'est pas moins parlant, c'est autre chose.

...
Je dirais que d'une manière générale, essaye d'éviter ce style d'écriture, même si cela fait partie de la norme C99. Cela amène beaucoup d'embrouille pour un avantage somme-toute assez réduit (je trouve, personnellement).

A quelle particularité de la C99 fais-tu allusion? aux VLA ?

...
Si tu es courageux: extern int *montableau Mais tu devras alors gérer manuellement chaque niveau de ton tableau.
Sinon, pour paraphraser ce que j'ai pu lire ici : "Une étoile par dimension supplémentaire" pour un tableau, donc extern int **montableau dans ton cas. (mais je m'attends à ce que l'on me reprenne sur cette affirmation.)

Et tu ne te trompes pas : il n'y a aucun rapport entre le nombre de dimensions et d'étoiles. C'est une faute de dire ceci, même avec l'intention de faire simple, car cette affirmation est fondamentalement fausse et induit une incompréhension totale des tableaux en C.

D'un autre coté, je ne suis pas sûr qu'on puisse avoir une déclaration extern qui ne soit pas strictement identique à celle de la variable.

De toute façon, int TAB[2][n] ne peut pas être en allocation statique mais doit être en allocation automatique (variable locale) et ne peut donc figurer en extern. Il faut revoir la conception des structures de données.

[latitude38]

Bonjour et avant tout, un grand merci de vos réponses !

Par rapport à celles-ci, il me reste encore quelques points problèmatiques:

* Tout d'abord la taille de TAB n'est pas variable puisque n ne change pas dans le programme. Mais j'imagine que pour la déclaration de référence, le fait que n varie ou pas dans le reste du code ne change rien à la confusion de cette écriture pour le compilateur.

*

Si tu es courageux: extern int *montableau Mais tu devras alors gérer manuellement chaque niveau de ton tableau

Que signifie "gérer manuellement chaque niveau de mon tableau" ?

*

Je dirais que d'une manière générale, essaye d'éviter ce style d'écriture, même si cela fait partie de la norme C99. Cela amène beaucoup d'embrouille pour un avantage somme-toute assez réduit (je trouve, personnellement).

Je ne comprend pas de quel style d'écriture tu parles. Parles tu de l'écriture 'extern' dans les headers ? De la déclaration de référence avec un pointeur ?

* D'après ce que j'ai maintenant compris, je vais déclarer TAB dans le header en passant par son adresse :extern int* TAB
Si cela ne passe du fait que la déclaration extern n'est pas strictement identique à celle de la variable, je pensais donc changer la déclaration-définition de TAB et en faire un pointeur.
Par exemple dans le main :

Code :

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

1
2
3
4
5
 
int** TAB;
TAB= (int**) malloc(2 * sizeof(int*));
for (i = 0; i < 2; i++)
        TAB[i] = (int*) malloc(n * sizeof(int));

et dans le header :

Code :

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

1
2
 
extern int** TAB

Est-ce que cela équivalent à l'usage d'un tableau ? (Je ne suis pas encore sûre de moi sur les pointeur et allocations de mémoire)

* dernière chose sur le principe : j'ai lu qu'il n'était pas recommandé d'utiliser beaucoup de variables globales. Mais il est également déconseillé d'avoir d'énormes liste d'argument à
l'entrée des fonctions.... Comment faire alors ??

Merci encore à vous

[latitude38]

Je viens d'avoir une idée, comme ma variable n ne varie pas de tout le programme, je peux en faire une macro et définir dans le header :

Code :

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

1
2
3
 
#define N 100
extern int TAB[2][N];

Qu'en pensez vous ?

[ternel]

Que ca change tout.

Une macro est remplacé par son "texte de remplacement" à la précompilation.

Ce qui sera effectivement compilé est extern int TAB[2][100];. Et là, tu as bien un tableau de taille connue à la compilation.