Discussion :

[Emmanuel Delahaye]

(Edit: Sal***rie d'IE7 qui remplace les espaces insécables par des astérisques...)

Firefox powa...

[Médinoc]

hegros : On ne reproche pas au prof de ne pas lui apprendre, mais de le basher pour avoir fait les choses comme elles doivent l'être...
Il y a une marge entre ne pas dire la vérité et apprendre des choses fausses.

Je sais, mais j'ai coupé l'accès de FF à Dvp.net pour réduire la dose au boulot...

[hegros]

[HS]
C'est au professeur de prendre en compte le niveau de ses éléves et de suivre le programme qu'il s'est fixé donc dire qu'il ne fait pas ce qui convient de faire ne me paraît pas raisonnable dans la mesure ou on ne connait et cela d'aucune façon le programme qu'il a établi pour cette formation.D'autant plus si il a déja distribué des polycops qui traite de ce sujet et que se sont les éléves qui ne les ont pas lu!

moralité : Ce n'est pas toujours de la faute des profs quand les éléves ne font pas ce qu'il faut faire
[/HS]

[Thierry Chappuis]

En castant la valeur retournée par malloc, on se prive de possibilités de vérification automatique réalisées par le compilateur. Je ne trouve pas si grave de le conseiller aux étudients, même si cela témoigne d'une certaine méconnaissance des enjeux. Je trouve toutefois regrettable de "jeter la pierre" à une élève alors que tous les spécialistes sur comp.lang.c ou sur dvp.net s'accordent à déconseiller l'utilisation de ce cast qui n'est utile qu'en C++ (et encore là, il vaut mieux utiliser les opérateurs new et delete).

Personnellement, je trouve plus préoccupant la façon dont on enseigne l'usage de scanf (très souvent mal maitrisé par les débutants, ce qui entraîne des comportement autrement plus dangereux que de caster le retour d'un malloc), ou même gets. Même si c'est au programme, et que c'est dans les polycopiés...

Thierry

[Clad3]

J'ai envoyé un mail parlant de ce problème à mon prof qui m'a répondu ceci, sans rien d'autre dans son mail (pas d'explication) et j'ai du mal à comprendre ce qu'il veux me faire comprendre, auriez vous une idée?

Code :

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

1
2
3
4
5
 
int main()
{
       char *plop = (char *) malloc(10);
}

A part qu'il alloue délibérément trop d'espace pour son pointeur je ne vois pas en quoi cela illustre la necessité d'un cast .

[hegros]

Tu lui as dis que le cast ne servait pas ?

[Clad3]

Je l'ai renvoyé sur ce topic, simplement.

[Emmanuel Delahaye]

J'ai envoyé un mail parlant de ce problème à mon prof qui m'a répondu ceci, sans rien d'autre dans son mail (pas d'explication) et j'ai du mal à comprendre ce qu'il veux me faire comprendre, auriez vous une idée?

Code :

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

1
2
3
4
5
 
int main()
{
       char *plop = (char *) malloc(10);
}

Tel quel ce code n'est pas portable, car malloc() est appelé sans prototype (pas de <stdlib.h> en vue). Il retourne donc un int, et celui-ci est casté en (char *), ce qui invoque un comportement dépendant de l'implémentation.

A part qu'il alloue délibérément trop d'espace pour son pointeur je ne vois pas en quoi cela illustre la nécessité d'un cast .

Là, par contre, tu fais des confusions. Ce code alloue un bloc de 10 char consécutifs, ce qui est tout à fait possible (tableau de 10 char). L'adresse du bloc est retournée par malloc() et celle-ci est stockée dans le pointeur pour un usage ultérieur.

Ceci est correct et portable :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
#include <stdlib.h>
 
int main (void)
{
   char *plop = malloc (10);
 
   /* test, utilisation, liberation... */
   return 0;
}

[Clad3]

Ce code alloue un bloc de 10 char consécutifs

Pour moi ce code alloue 10 octect consécutif et non 10 char, hum sauf bien sur si un char fait 1 octect quelles que soit la machine / le compilateur utilisé.

En admettant que l'on ai 10 char [ 10*szeof(char) ou 10*sizeof( *plop ) ], en quoi cela illustre-t-il la nécessité d'un cast ( car je supose que c'est un exemple visant à me montrer cela que mon prof m'a envoyé .... ) .


edit: A mon avis il n'a pas inclu stdlib.h juste car il a du écrire un exemple a la va vite, donc on va suposer que la lib est incluse .

[hegros]

La confusion du cast tient son origine peut être aussi parce que le prototype de malloc spécfie que cette fonction renvoi un void*.

[Emmanuel Delahaye]

Pour moi ce code alloue 10 octect consécutif

Non. C'est bien 10 char. L'unité de compte de la taile d'un objet est le char (ou byte) quelque soit la machine, et elle vaut 1 (comme toutes les unités). La taille d'un char en bits est d'au moins 8. Ca peut être plus. Voir CHAR_BIT dans <limits.h>

En admettant que l'on ai 10 char [ 10*szeof(char) ou 10*sizeof( *plop ) ], en quoi cela illustre-t-il la nécessité d'un cast ( car je supose que c'est un exemple visant à me montrer cela que mon prof m'a envoyé .... ) .

Je n'en ai aucune idée, il faut lui demander. On est pas dans la tête de ton prof... J'ai juste relevé que le code était non portable. Peut être a-t-il voulu masquer l'incohérence int/char* signalée par son compilateur avec un cast...

edit: A mon avis il n'a pas inclu stdlib.h juste car il a du écrire un exemple a la va vite, donc on va suposer que la lib est incluse .

Quelle 'lib' ? Tu parles du fichier d'en-tête ? La moité des problèmes d'incompréhension du langage C sont dus à une mauvaise utilisation du vocabulaire. Il faut apprendre à être précis dans le choix de ses mots.

Dans ce cas, le cast est totalement inutile. Je ne sais pas ce que ton prof a voulu prouver.

[Emmanuel Delahaye]

La confusion du cast tient son origine peut être aussi parce que le prototype de malloc spécfie que cette fonction renvoi un void*.

Le cast avait un sens en C pré-Ansi, avant l'invention du mot 'void'. malloc() retournait alors un char*, et oui, il fallait caster. Mais bon, c'était avant 89. J'ai commencé le C en 88 (TC 2.0)... BC 3.0 (ANSI) est sorti en 90.

[Clad3]

Je viens de voir que en effet sizeof(char) est bien de 1 et ca semble assuré.

Quelle 'lib' ? Tu parles du fichier d'en-tête ? La moité des problèmes d'incompréhension du langage C sont dus à une mauvaise utilisation du vocabulaire. Il faut apprendre à être précis dans le choix de ses mots.

Mea culpa, j'ai régidé ce message trop vite, (dans ma tête "stdLIB" donc j'ai écrit lib ...) Bref je parlais du fichier d'entête stdlib.h .