difference entre 2 ecritures

bonjour
quel est la difference entre ces deux ecritures?

Code:

---

*tab[n] = (l_word) malloc(sizeof(l_word));

---

et

Code:

---

tab[n] = (l_word*) malloc(sizeof(l_word));

---

merci d'avance

Bonjour,

Peux-tu nous donner la définition de tab et l_word stp ?

PS : mon 3000e message !

Bonjour,

Est-ce un devoir scolaire ?

Ces deux expressions sont totalement différentes, et la première ne serait même correcte que si l_world était issu d'un typedef qui masquerait un pointeur, chose courante dans les écoles et pourtant proscrite par pratiquement tous les habitués du langage C.

La seconde place dans l'entrée n du tableau tab le pointeur renvoyé par malloc, ce qui semble être une bonne chose. La première, en revanche, déférence le pointeur qui s'y trouve déjà et va déposer à l'endroit qu'il pointe la valeur renvoyée par malloc et préalablement transtypée en l_world… à condition que ce soit possible, faute de quoi ton programme ne compilera pas.

Citation:

---

Envoyé par Bktero

Bonjour,

Peux-tu nous donner la définition de tab et l_word stp ?

---

les voici

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

typedef struct t_word{ char *mot; struct t_word *next; } t_word;   typedef struct t_word *l_word;   typedef struct liste{ l_word first; l_word last; int qte; }liste;

---

Code:

---

1 2 3 4 5 6 7 8 9

l_word *init_tab_hach(){ l_word *tab[100]; int n = 0; while(n < 100){ *tab[n] = (l_word) malloc(sizeof(l_word)); n++; } return *tab; }

---

j'essai de travailler la notion de tableau de pointeur

Tel qu'écrit actuellement, ton programme ne fonctionnera pas et déclenchera probablement une segfault :

Code:

---

1 2 3 4

l_word *tab[100]; int n = 0; while(n < 100){ *tab[n] = (l_word) malloc(sizeof(l_word));

---

Tu déclares un tableau de cent pointeurs, lesquels ne sont pas initialisés a priori et ne pointent donc sur rien. Dans la boucle, tu « utilises » le pointeur pour aller stocker à l'endroit qu'il pointe la valeur renvoyée par malloc. Comme ton pointeur pointe n'importe où, et en aucun cas vers un espace mémoire dûment initialisé au préalable, ton programme est voué au crash.

Quand, en revanche, tu écris tab[n] = (l_word *) malloc(sizeof(l_word)), alors tu indiques que c'est au pointeur lui-même que tu veux affecter quelque chose (et pas à ce qu'il pointe), et que le pointeur renvoyé par malloc est un « pointeur vers un l_world », ce qui est cohérent en soi (adresse mémoire du début espace alloué) ainsi qu'avec la définition de ton « tableau de pointeurs » : l_word *tab[100], où tu déclares bien un « tableau de cent pointeurs vers un l_word », ce qui correspond à ce qui est renvoyé par l'expression à droite de « = ».

J'ajoute que si tu programmes vraiment en C et si tu utilises un vrai compilateur C, alors tu n'as pas besoin de ces casts explicites sur le pointeur retourné par malloc(): En C, contrairement au C++, void* est implicitement convertible en pointeurs vers les autres types.

Citation:

---

Envoyé par Obsidian

Tel qu'écrit actuellement, ton programme ne fonctionnera pas et déclenchera probablement une segfault :

Code:

---

1 2 3 4

l_word *tab[100]; int n = 0; while(n < 100){ *tab[n] = (l_word) malloc(sizeof(l_word));

---

Tu déclares un tableau de cent pointeurs, lesquels ne sont pas initialisés a priori et ne pointent donc sur rien. Dans la boucle, tu « utilises » le pointeur pour aller stocker à l'endroit qu'il pointe la valeur renvoyée par malloc. Comme ton pointeur pointe n'importe où, et en aucun cas vers un espace mémoire dûment initialisé au préalable, ton programme est voué au crash.

Quand, en revanche, tu écris tab[n] = (l_word *) malloc(sizeof(l_word)), alors tu indiques que c'est au pointeur lui-même que tu veux affecter quelque chose (et pas à ce qu'il pointe), et que le pointeur renvoyé par malloc est un « pointeur vers un l_world », ce qui est cohérent en soi (adresse mémoire du début espace alloué) ainsi qu'avec la définition de ton « tableau de pointeurs » : l_word *tab[100], où tu déclares bien un « tableau de cent pointeurs vers un l_word », ce qui correspond à ce qui est renvoyé par l'expression à droite de « = ».

---

merci c'est desormais un peu plus clair dans mon esprit maintenant

Citation:

---

Envoyé par Médinoc

J'ajoute que si tu programmes vraiment en C et si tu utilises un vrai compilateur C, alors tu n'as pas besoin de ces casts explicites sur le pointeur retourné par malloc(): En C, contrairement au C++, void* est implicitement convertible en pointeurs vers les autres types.

---

du coup quel est l'avantage et l’utilité du casts?
car on m'a fait comprendre qu'avec un cast on était sur qu'il y aurait pas de problème
et qu’apparemment le programme serait portable

Le cast du retour de malloc() est une légende urbaine, les auteurs du K&R2 ont mentionné dans l'Errata qu'ils n'auraient pas dû l'inclure. Il ne sert à rien, ne rend "portable" qu'avec des compilos C complètement obsolètes ou des compilos qui ne sont même pas prévus pour le C, et en fait d'absoudre de tout problème peut même cacher des erreurs à la compilation.

Citation:

---

Envoyé par chrislains

du coup quel est l'avantage et l’utilité du casts?
car on m'a fait comprendre qu'avec un cast on était sur qu'il y aurait pas de problème
et qu’apparemment le programme serait portable

---

D'une manière générale, un transtypage (cast) convertit un type de donnée vers un autre, sous réserve que le compilateur sache le faire. C'est une opération très courante en informatique et pas seulement en C. Par contre, ça va surtout être flagrant avec les types natifs du C qui, si l'on excepte les flottants float et double, se ramènent quasiment toujours à des nombres entiers de différentes largeurs.

Le transtypage peut être implicite. Par exemple :

Code:

---

1 2 3 4

unsigned char a; unsigned long b;   a = b;

---

On remarque immédiatement que puisque un char est moins large qu'un long, il va y avoir perte d'information, mais ce n'est pas forcément incohérent en soi si la donnée appartient aux deux domaines. Dans cet exemple, le compilateur va le faire tout seul mais on comprend assez vite qu'en règle générale, pour pouvoir faire une affectation avec « = », il faut que le type de donnée soit le même des deux côtés. Parfois, la conversion peut se faire naturellement et sans heurt (exemple : char vers int) mais le plus souvent, le compilateur ne saura pas si c'est volontaire ou fortuit, et donc s'il faut afficher un avertissement (warning) ou pas. Cela va être typiquement le cas lors de comparaisons entre entiers signés et non signés, qui sont représentés exactement de la même manière mais interprétés différemment par le lecteur (ou le processeur).

Dans le cas d'un pointeur, c'est encore plus subtil car quelque soit ce qu'il pointe, ce qu'il contient reste une adresse mémoire. On pourrait très bien imaginer que des adresses mémoires soient incompatibles entre elles (par exemple dans le cas des architectures Harvard, dont les bus réservés au code et aux données sont distincts, et même pas forcément du même format) mais la plupart du temps, il s'agit du même plan mémoire et quand ils pointent en RAM, une donnée peut très bien être remplacée par une autre de nature différente et dans ce cas, il faut transtyper le pointeur même si, en pratique, l'adresse qu'il contient reste la même.

Dans cet esprit, il existe les pointeurs « void * » qui servent à dire justement qu'il s'agit d'une adresse mémoire à laquelle ne se trouve rien de défini (ou connu) en particulier a priori. C'est typiquement adapté à malloc() qui se contente de réserver de l'espace, à la discrétion de l'utilisateur. Par contre, un pointeur « void * » aura forcément vocation a être transtypé en quelque chose de plus précis pour pouvoir être utilisé.

Ce qu'explique Médinoc, donc, c'est qu'en vertu tout ce que l'on vient de dire, il est naturel de transtyper un pointeur « void * » quand on l'affecte à sa variable définitive et que c'est même exigé par le C++, mais que puisque c'est nécessaire (et que cela n'engendre de toutes façon aucune modification de sa valeur propre) alors c'est considéré comme implicite par le C, qui considère alors comme tout-à-fait régulier de faire l'affectation directement sans transtypage explicite.