Discussion :

[Claude URBAN]

Bonjour,

Tout est dans le titre, ou presque.

Je suis sous Windows 8.1, IDE Code::Blocks 13.12 et je m'initie doucement au C et à la bibliothèque SDL 2.0.

Je suis en train d'essayer de retranscrire un Labyrinthe, que j'avais fait et qui fonctionne sous wxLua.

Mais là n'est pas le problème.

Pour le moment, je souhaiterais pouvoir créer une table dynamique à 2 dimensions dans une structure.

Mon compilateur utilise le C99, qui si j'ai bien compris me permet de ne pas utiliser "malloc".

Si je déclare mon tableau dynamique 2 dimensions dans une fonction (pas dans la structure), ça fonctionne.

Si je déclare un tableau dynamique à 1 dimension dans la structure, ça fonctionne.

A deux dimensions, ça plante, pas à la compilation mais au lancement du programme.

Dans ma structure j'ai bien défini mon tableau avec 2 étoiles: **t_cases;

Je définis bien ma variable de structure, j'appelle sans problème les autres variables.

Je ne sais plus où chercher...

Un petit bout de code, peut-être?

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
 
Dans main.h
 
typedef struct s_labyrinthe s_labyrinthe;
struct s_labyrinthe
{
... ... ...
Uint16 **t_cases;
.... .... ....
};
 
Dans le main
int main(int argc, char *argv[])
{
s_labyrinthe data; // définition de la variable de structure
 
// définition des variables lignes colonnes.
 Uint16 xCases = data.Longueur - data.dx;
 Uint16 yCases = data.Largeur - data.dy;
 
data.t_cases[xCases][yCases];  // dans cette exemple je ne vais pas plus loin, c'est la que ça plante...
... ... ...
 
return 0;
}

Merci pour toute l'aide que vous pourrez m'apporter et bonne journée à vous.


Claude.

[Invité]

Bonjour,

Il te manque l'allocation de mémoire de ton pointeur, sans quoi il pointe vers une zone aléatoire non réservée à laquelle tu n'as aucun accès.
Voir ce sujet de la FAQ pour ce faire.

[Trademark]

Dans ton cas tu devras obligatoirement passer par malloc & co. Je pense que tu avais lu quelque chose à propos des VLA mais c'est assez limité vu que ça alloue sur la pile (et non pas sur le tas).

[Claude URBAN]

Merci à tous les deux pour avoir répondu à mon appel au secours aussi rapidement.

@Winjerome:

Oui et non.

Car ta solution préconise l'utilisation de "malloc" que je voudrais éviter. Et justement en VLA = pas besoin.

J'avais commencé comme ça (avec malloc) et je te dis pas comment je me suis emmêlé les pinceaux...

Donc j'ai changé mon fusils d'épaule.

Et comme je dis plus haut, si je ne passe pas par la structure mais directement dans une fonction, ça fonctionne en dynamique et tout et tout... mais bon, je voudrais comprendre pourquoi et en plus la structure ça me semble être une bonne idée!

@Trademark:

OUI, je fais allusion à la VLA, qui fonctionne hors structure, pas de malloc, pas de free... super!

Peut-être est-ce justement la structure qui pose problème, dans le cas d'un tableau bidimensionnel?

Si quelqu'un peut confirmer ou infirmer... d'avance merci.

[Invité]

Utiliser un pointeur, et ne pas vouloir utiliser malloc/free, c'est juste pas compatible.
Et en effet il n'est pas possible d'avoir de champ VLA dans une structure. La solution approchante consiste à utiliser un flexible array member, mais on en revient à l'utilisation de malloc
Reste la solution d'une taille de tableau maximale fixée à la compilation.

[Trademark]

Note que c'est peut-être bête à dire mais si tu veux des solutions plus élégantes tu peux toujours utiliser un autre langage... comme C++ :-)

Mais dans n'importe quelle langage tu devras allouer dans le tas et utiliser des équivalents à malloc/free (bien qu'il puisse être caché et donc rendre la solution plus élégante).

[Obsidian]

Peut-être est-ce justement la structure qui pose problème, dans le cas d'un tableau bidimensionnel?

Si quelqu'un peut confirmer ou infirmer... d'avance merci.

Ton problème vient du fait que ce n'est pas un tableau que tu as déclaré dans ta structure, mais un pointeur.

Un pointeur est une bête variable qui contient l'adresse mémoire de quelque chose d'autre. C'est notamment pour cela que ce pointeur aura toujours la même taille. Quelque soit l'objet auquel il se réfère, une adresse mémoire, c'est une adresse mémoire. Et celle-ci a toujours le même format. Le fait d'avoir ajouté deux étoiles indique simplement que ce qui est pointé par ton pointeur est… un autre pointeur, qui lui pointe à son tour un uint16. Tu peux indexer ton pointeur comme un tableau pour récupérer facilement l'élement qu'il pointe et tous les suivants s'il y en a. Il en reste que tu n'as pas initialisé ton pointeur, ce qui normal puisque tu n'as pas réservé de mémoire. Tu aurais pu t'en rendre compte seul en te posant la question « quelle taille a mon tableau ? ». Tu ne précises cela nulle part.

D'autre part, en C, un tableau n'est pas un objet managé. C'est simplement et uniquement la réservation de la place nécessaire à ses éléments, à l'octet près. Ni plus ni moins. Il n'y a pas de méta-données cachées à l'arrière-plan servant à sa gestion, et c'est entre autres pour cela que tu ne peux pas le redimensionner a posteriori. Tout est censé être préparé à la compilation et le tout est résolu en différents offsets pouvant même être codés en dur dans l'exécutable.

Les VLA ne sont pas non plus des tableaux redimensionnables, mais leur taille peut quand même être spécifiée à l'exécution, notamment en suivant la valeur d'une variable. Cela à la condition qu'il s'agisse bien de tableaux locaux et pas globaux. C'est possible car les variables et tableaux locaux vont dans la pile et que la place nécessaire y est réservée chaque fois que tu entres dans une fonction. Il n'est alors pas (beaucoup) plus compliqué de retrancher au pointeur de pile la valeur d'une variable plus qu'une constante précalculée.

Est-ce à dire qu'il est possible de déclarer des VLA indépendants mais pas au sein d'une structure ? En fait, si, c'est possible… à condition de déclarer le type de ta structure (oui, la structure elle-même, pas seulement une de ses instances) au sein du même bloc. Ça réduit de beaucoup l'intérêt de la structure, que tu ne pourras pas passer non plus telle quelle à une autre fonction (qui ne la connaîtrait pas), mais c'est possible.

[Claude URBAN]

Bonjour,

Tout d'abord un grand merci à vous trois pour vos réponses qui m'ont permis de mieux comprendre " le coté" obscure des tableaux... "

@Trademark:

J'avais l'habitude de faire de la petite programmation sous "wxLua avec wxWidgets" et je n'ai jamais rencontré ce genre de problème.

La construction de tableau (simple ou double) sous "lua" est extrêmement simple.

Mais c'est complètement différent, il s'agit d'un langage interprété et non compilé.

Quand au C++, si je ne m’abuse, il n'est pas question de "malloc et free" mais de "new et delete", ça change de nom, mais ça revient à peu près au même... il faut gérer soi-même la mémoire.

Mon problème vient du fait, je pense, que j'ai l'habitude de construire des tableaux avec lua alors qu'en C, c'est complètement différents.

Je me dois de voir les choses différemment et comme me rappelle @Obsidian: "... en C, un tableau n'est pas un objet managé... ".


Mais pour revenir à nos moutons.

En confirmation (ci-besoin est?) de ce qui ressort de vos commentaires, j'ai trouvé ça, hier soir sur le Net, à cette adresse: https://prof.hti.bfh.ch/fileadmin/ho...anuscrit_C.pdf:

Depuis le nouveau standard C99, il y existe également des tableaux avec des tailles variables (anglais Variable Length Array (VLA)).
Les VLAs peuvent uniquement être définis à l'intérieur des blocs.
Ils ne peuvent être ni globaux ni statiques et ne peuvent pas être définis à l'intérieur des structures.
La taille des VLAs, qui est fixée à leur génération, reste constante pendant toute leur existence.

Par analogie aux arrays conventionnels, il n'existe pas de limitation en ce qui concerne la dimension des VLAs.
Les VLAs peuvent être transmis comme arguments à des fonctions.
Dans ce cas, la taille de l'array doit être transmise séparément.
Dans la liste des paramètres, la taille doit se trouver devant le nom de l'array.
Lorsque les VLAs sont multidimensionnels, il faut transmettre la taille de toutes ses dimensions.

Compte tenu de l'origine du document, je pense que l'on peut lui faire confiance et en plus ça a l'avantage d'être clair... enfin, je trouve.

Donc pour revenir à mon problème: trois solutions s'offrent à moi.

1/ Créer mon tableau sous forme d'une variables "globale". ... Mais c'est pas terrible à éviter.

2/ Créer mon tableau dans une structure, en utilisant la bonne vielle méthode des "malloc/free"... ou en lui donnant une taille fixe.

3/ Utiliser la VLA dans un bloc (une fonction) en dehors de ma structure. (mais apparemment, j'ai cru comprendre que la solution des VLA n'avait pas une bonne côte du coté des professionnels... pourquoi?)


Mais je ne suis pas un professionnel de l'informatique, simplement un amateur passionné.

Donc si un "pro" passe par là, peut être pourrait-il s'arrêter 5 minutes pour me donner son avis sur la meilleur stratégie à adopter.

Histoire de bien faire les choses, simplement.

Merci et bonne journée.

Claude.

[Médinoc]

Utiliser un pointeur, et ne pas vouloir utiliser malloc/free, c'est juste pas compatible.
Et en effet il n'est pas possible d'avoir de champ VLA dans une structure. La solution approchante consiste à utiliser un flexible array member, mais on en revient à l'utilisation de malloc
Reste la solution d'une taille de tableau maximale fixée à la compilation.

Les flexible array members ne peuvent être flexibles que sur une seule dimension, comme les tableaux en paramètre de fonction, n'est-ce pas? Sinon on ne pourrait pas les indexer...

[Trademark]

Pour répondre à ta remarque sur le C++, ce n'est pas totalement vrai, il y a des mécanismes beaucoup plus élégants et un programme peut maintenant être écrit sans aucun new/delete. Pour ton tableau 2D tu pourrais le déclarer comme ceci std::vector<std::vector<std::uint16_t>>.

Enfin quoi qu'il en soit c'est un autre langage au même titre que Java ou Python, donc ça ne répond pas à ta question.

Je pense qu'il faut revenir un peu aux sources pour que tu comprennes les tenants et aboutissants et notamment à la notion de pile et tas. Un programme est constitué de ces deux structures et tu les manipules inconsciemment. À chaque appel de fonction, son contexte est placé sur la pile est ne sera pas accessible autre part ! Par exemple :

Code :

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

1
2
3
4
5
void foo()
{
  int a = 5; // 5 est mis sur la pile.
  bar(); // bar ne pourra pas accéder à 5.
}

Il faut garder à l'esprit que ça se comporte réellement comme une pile : tu ne peux accéder qu'à l'élément du dessus (soit la dernière fonction appelée). L'empilage et le dépilage se fait automatiquement. Une autre contrainte importante est que la pile est généralement limitée en taille, par exemple à 8Mb mais ça dépend de ton système d'exploitation, donc si tu essayes d'allouer un tableau trop gros ou de faire des appels de fonction récursifs qui "récursent" trop, tu auras une erreur nommée "stack overflow". Je pense que c'est principalement pour ça que les gens n'aiment pas les VLA, tu l'initialises avec une variable qui n'est connue qu'à l'exécution et c'est donc un moyen de faire planter ton programme si tu n'as pas vérifier que la taille de cette variable était raisonnable.

Le tas, quant-à-lui, est une région de mémoire qui n'est pas géré par le système, c'est à toi d'allouer un morceau dedans avec malloc et de le libérer ensuite. Cette zone de mémoire est accessible partout dans ton programme via des adresses que tu stocks dans des pointeurs. Si tu ne libères pas la mémoire tu auras une fuite de mémoire et la zone restera occupée jusqu'à la fin de ton programme. Cette zone est aussi beaucoup plus large, mais il ne vaut mieux pas dépasser la capacité de ta RAM sinon tu auras de gros problème de performance (pour des données plus grosses il faudra passer par des fichiers).

Voila pour ce que j'en sais ;-)

[Obsidian]

En confirmation (ci-besoin est?) de ce qui ressort de vos commentaires, j'ai trouvé ça, hier soir sur le Net, à cette adresse: https://prof.hti.bfh.ch/fileadmin/ho...anuscrit_C.pdf:

Compte tenu de l'origine du document, je pense que l'on peut lui faire confiance et en plus ça a l'avantage d'être clair... enfin, je trouve.

Effectivement, j'ai dit une ânerie hier soir (j'étais fatigué). Même si tu déclares ta structure en local dans un bloc, il n'en reste pas moins que les offsets des membres de cette structure sont quand même calculés à l'avance et que le problème demeure. Donc, pas de VLA au sein d'une structure. Il arrive en revanche que certains programmes utilisent des types incomplets, en collant le tableau à la fin de la structure. Mais ça ne t'aidera pas dans le cas présent.

Par contre, méfie-toi de la fiabilité des sources de tes documents. Un document écrit par un professeur pour le compte d'une école donnée a certes des chances d'avoir été scrupuleusement vérifié mais ce n'est pas un gage de référence. D'abord parce que l'informatique est encore très récente par rapport aux millénaires du reste de l'édifice mathématique et qu'il est difficile pour les enseignants d'être toujours à jour. Ensuite, parce qu'il y a également beaucoup de guerres de chapelles en programmation. Donc, quelqu'un qui va avoir tendance a t'asséner des vérités toutes faites avec force et t'expliquer quelle est la meilleure façon de coder est en général quelqu'un dont on peut souvent remettre les idées en cause.

Donc pour revenir à mon problème: trois solutions s'offrent à moi.

1/ Créer mon tableau sous forme d'une variables "globale". ... Mais c'est pas terrible à éviter.

2/ Créer mon tableau dans une structure, en utilisant la bonne vielle méthode des "malloc/free"... ou en lui donnant une taille fixe.

C'est ce qui se fait le plus fréquemment. Il faut juste ne pas oublier de libérer l'espace concerné avec free() en fin de traitement.

3/ Utiliser la VLA dans un bloc (une fonction) en dehors de ma structure. (mais apparemment, j'ai cru comprendre que la solution des VLA n'avait pas une bonne côte du coté des professionnels... pourquoi?)

Je ne sais pas si les VLA ont ou non une bonne cote mais les seules raisons qui me viennent à l'esprit sont que, d'une part, les VLA ont été introduits avec C99 et, la plupart du temps, on essaie de rester compatible avec le C ANSI 89 lorsque c'est possible. L'autre raison est que ça empêche de calculer a priori une taille minimum pour la pile. Ça peut être gênant dans l'embarqué, rarement ailleurs.

[Claude URBAN]

Comme j'aime à dire: "Le savoir ne vaut que s'il est partagé par tous..."

Un très grand merci donc à vous tous, pour toute l'aide que vous venez de m'apporter dans ma compréhension des tableaux, malloc, free, VLA et compagnie.

Pour mon apprentissage, j'ai mis en application les deux méthodes, VLA et malloc.

Mais je ferai mon programme avec malloc, que j'ai enfin réussi à maîtriser.

Une dernière question reste en suspend puisque j'ai décidé d'utiliser malloc.

Celle de l'utilisation de free().

Question à laquelle ma propre réponse qui me semblait évidente et logique me turlupine.

Et me turlupine encore plus, depuis que je viens de lire:

Il faut juste ne pas oublier de libérer l'espace concerné avec free() en fin de traitement.

Etant donné qu'il s'agit d'une structure, si je libère la mémoire avec free(), je n'aurais plus de structure...

Donc si j'ai bien compris, dans le cas d'une structure, il ne faux pas utiliser free() en cours de route.

Sauf peut-être avant de quitter le programme.

Est-ce la signification de: "..en fin de traitement."( = fin de programme.)


Bonne fin de journée et bon week-end.

Claude.

[Obsidian]

Une dernière question reste en suspend puisque j'ai décidé d'utiliser malloc.
Celle de l'utilisation de free().
Question à laquelle ma propre réponse qui me semblait évidente et logique me turlupine.

Et me turlupine encore plus, depuis que je viens de lire:
Etant donné qu'il s'agit d'une structure, si je libère la mémoire avec free(), je n'aurais plus de structure...
Donc si j'ai bien compris, dans le cas d'une structure, il ne faux pas utiliser free() en cours de route.

En fait, tout cela est passablement simple. Il faut juste garder à l'esprit que l'on travaille toujours « sous la couche objet » et qu'il n'y a que très peu de choses qui soient exécutées « implicitement », à l'insu du programmeur.

Lorsque tu utilises malloc(), tu demandes au système d'exploitation (et pas au compilateur) de te réserver de la mémoire lors de l'exécution. Celui-ci va alors te renvoyer un pointeur pour t'indiquer où elle se trouve. C'est donc à toi de sauvegarder cette adresse quelque part. Mais c'est également à toi de lui indiquer quand tu as fini de t'en servir parce qu'il ne peut pas le deviner lui-même, et parce que tu auras probablement besoin de la libérer sur un événement particulier (par exemple, une action de l'utilisateur) et pas sur la fin d'un bloc ou d'une fonction. Tu libères donc cette mémoire en passant le même pointeur à free().

Il est tout-à-fait opportun de sauver l'adresse de la mémoire allouée dans un des membres d'une structure. C'est même comme cela qu'on construit, peu à peu, des objets évolués. Mais ces structures ne sont pas dotées de destructeurs comme on les trouve dans les langages évolués. Donc, si tu détruis la structure, tu perds son contenu, c'est-à-dire l'adresse de la mémoire allouée, entre autre. Mais cette mémoire n'est absolument pas corrélée de manière officielle à ta structure, si bien que si tu ne sais plus où elle se trouve, tu ne peux plus la libérer, et cela conduit à des fuites de mémoire.

[Kannagi]

Est-ce la signification de: "..en fin de traitement."( = fin de programme.)

Fin de traitement veut dire quand tu n'en a plus besoin , ça peut être a la fin de ton programme , a la fin d'une fonction ou ailleurs , tout dépend quand tu n'en a plus besoin.

[Claude URBAN]

Bonjour,

C'est maintenant, nettement plus claire dans mon esprit.



Pour la bonne forme, je mets ce post en "résolu", mais ne manquerai pas de revenir vous voir plus tard... pour d'autres questions.

Bon week-end.

Claude