Discussion :

[corrector]

Or donc, il y aura 2 notions à indiquer : une qui est que le cast est déconseillé, l'autre qu'il faut le mettre... Bof... Pas très pédagogique... Et surtout générateur d'erreurs (ou plutôt de "légéretés" plus tard).

Justement, ce qu'un pédagogue voudra faire passer, c'est que l'important, c'est de comprendre le typage et de savoir quand il faut mettre un cast.

Sinon, c'est très facile de coller des casts dès que le compilateur râle à propos d'un problème de type, sans essayer de comprendre pourquoi il râle. C'est la plus rapide méthode pour faire des programmes qui compilent mais ne fonctionnent pas (ça, et les mauvaises manipulations de pointeurs).

Voir pleins de casts dans un programme est souvent indicatif d'une mauvaise programmation (ou alors, qu'on ne peut pas faire autrement).

[souviron34]

que ce soit dans C99, ok.

Mais par exemple dans K&R :

Code :

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

1
2
3
4
5
6
7
 
#include <stdlib.h> 
/* talloc: make a tnode */ 
struct tnode *talloc(void) 
{ 
return (struct tnode *) malloc(sizeof(struct tnode)); 
}

ou

Code :

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

1
2
3
4
5
6
7
8
9
 
char *strdup(char *s) /* make a duplicate of s */ 
{ 
char *p; 
p = (char *) malloc(strlen(s)+1); /* +1 for '\0' */ 
if (p != NULL) 
strcpy(p, s); 
return p;
}

pour n'en citer que 2...

Bref, de toutes façons, ce que je dis c'est que les arguments ne sont pas logiques....

En cas d'oubli de l'inclusion de stdlib.h, la malloc() n'est pas déclarée. Dans ce cas, le compilateur suppose que malloc() retourne un entier de type int. Or, la conversion implicite d'un entier de type int en un pointeur n'est pas légale et le compilateur renvoie une erreur. Par contre, si une conversion explicite est effectuer, le compilateur comprendra "je sais que je fais quelque chose de pas catholique, mais je le sais" et ne renverra pas d'erreur. On se prive ainsi qu'une possibilité de vérification automatique par le compilateur.

Plus grave (toujours en cas d'oubli de stdlib.h), sur les systèmes 64 bits où un pointeur est représenté sur 64 bits et un int sur 32, la valeur retournée par malloc(), considérée comme un entier de type int par le compilateur, sera tronquée à 32 bits.

Encore une fois, qui en dehors des débutants oublie stdlib.h dans un programme ?????????????????????

[millie]

parce que dans la vraie vie, sur de très gros softs, ça arrive....

Tu aurais pu prendre l'exemple des adresse socket :

Code :

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

1
2
3
4
5
struct sockaddr {
   unsigned char   sa_len;         /* longueur totale 		*/
   sa_family_t     sa_family;      /* famille d'adresse 	*/
   char            sa_data[14];    /* valeur de l'adresse	*/
};

Code :

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

1
2
3
4
5
6
7
struct sockaddr_in {
   uint8_t         sin_len;       /* longueur totale      */
   sa_family_t     sin_family;    /* famille : AF_INET     */
   in_port_t       sin_port;      /* le numéro de port    */
   struct in_addr  sin_addr;      /* l'adresse internet   */
   unsigned char   sin_zero[8];   /* un champ de 8 zéros  */
};

La structure assez particulière fait qu'il est nécessaire de caster les sockaddr_in en sockaddr, par exemple avec :

Code :

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

int connect(int sockfd, struct sockaddr *serv_addr, socklen_t addrlen);

[Médinoc]

Souviron34 : Comme Emmanuel l'a souvent souligné, il faut lire tout le K&R, y compris les errata.

142(§6.5, toward the end): The remark about casting the return value of malloc ("the proper method is to declare ... then explicitly coerce") needs to be rewritten. The example is correct and works, but the advice is debatable in the context of the 1988-1989 ANSI/ISO standards. It's not necessary (given that coercion of void * to ALMOSTANYTYPE * is automatic), and possibly harmful if malloc, or a proxy for it, fails to be declared as returning void *. The explicit cast can cover up an unintended error. On the other hand, pre-ANSI, the cast was necessary, and it is in C++ also.

[souviron34]

bon j'arrêterais là, mais même dans ce que tu cites :

possibly harmful if malloc, or a proxy for it, fails to be declared as returning void *.

Je reviens encore une dernière fois :

qui en dehors des débutants oublie stdlib.h dans un programme ?????????????????????



Ce qui est le seul argument.... (or stdlib déclare comme void *)

Donc....

[Médinoc]

Non, l'autre argument est que c'est inutile, et un troisième est que ça a l'avantage de ne pas compiler en C++.

[souviron34]

, et un troisième est que ça a l'avantage de ne pas compiler en C++.

et on entretient la confusion (ou la difference, suivant le point de vue ou on se place) entre C et C++....

[Médinoc]

Ou plutôt, on met l'accent sur le fait que ce soient deux langages différents. Et ainsi, on peut éviter que quelqu'un fasse un bête copier-coller du code et tente de le compiler sur un compilateur C++ alors qu'il n'est pas fait pour ça...

[Garulfo]

[...]
qui en dehors des débutants oublie stdlib.h dans un programme ????????????????????? [...]

Tu dois être très très bien placé par ton expérience pour savoir que les erreurs d'inattention peuvent survenir chez n'importe qui non ? Et qu'il y a des domaines où on ne veut même pas prendre ce risque.

Et l'argument de la « non compilation en C++ » est aussi une bonne raison.

[souviron34]

Tu dois être très très bien placé par ton expérience pour savoir que les erreurs d'inattention peuvent survenir chez n'importe qui non ? Et qu'il y a des domaines où on ne veut même pas prendre ce risque.

Et l'argument de la « non compilation en C++ » est aussi une bonne raison.

si on programme pour C, on s'en fiche de ce qui se passe en C++

Et pour le reste, je suis bien place pour dire que dans tous les projets sur lesquels j'ai travaille depuis plus de 19 ans, il y a un fichier "Project_Common_C.h" qui inclus tous les entetes standards utiles en general (stdio, stdlib, time, math et quelques autres), qui est a inclure dans tout fichier

Donc je refute ces arguments

[Jean-Marc.Bourguet]

Absence de cast de void* en X*, en particulier sur le résultat de malloc.

Pourquoi?

C'est idiomatique mais à part cela, il n'y a pas de très bonnes raisons
fondamentale. La plus profonde étant peut-être une volonté d'écrire
quelque chose qui ne compile pas en C++, les autres tiennent plus de la
rationalisation que d'autre chose.

Voici quelques explications:

• C'est inutile!

• Ca reste à justifier. Il y a un effet de documentation pas négligeable.
  
  

• En cas d'oubli de l'inclusion de stdlib.h, la malloc() n'est pas
  déclarée. Dans ce cas, le compilateur suppose que malloc() retourne un
  entier de type int. Or, la conversion implicite d'un entier de type int en
  un pointeur n'est pas légale et le compilateur renvoie une erreur. Par
  contre, si une conversion explicite est effectuer, le compilateur
  comprendra "je sais que je fais quelque chose de pas catholique, mais je le
  sais" et ne renverra pas d'erreur. On se prive ainsi qu'une possibilité de
  vérification automatique par le compilateur.
• Plus grave (toujours en
  cas d'oubli de stdlib.h), sur les systèmes 64 bits où un pointeur est
  représenté sur 64 bits et un int sur 32, la valeur retournée par malloc(),
  considérée comme un entier de type int par le compilateur, sera tronquée à
  32 bits.

[Vincent Rogier]

Pour ma part, au sujet du cast de la valeur de retour de malloc:

* l'argument "inutile" est cohérent, même si la remarque Jean-Marc.Bourguet sur l'effet 'documentation' est valable

* l'argument "dangeureux" en cas d'oubli d'inclusion de sdtlib.h n'est pas valable. Un compilo bien réglé ne peux laisser passer ca.

J'ai du mal à imaginer qu'un développeur sérieux puisse livrer ou mettre en prod des applis compilées avec un compilo si mal réglé.

Je pense que fondamentalement, la seule raison qui fasse déconseiller le cast de la valeur de retour de malloc en C est de rendre le source incompilable en C++, hormis le fait que le cast est intrinsèquement inutile !

[Garulfo]

Donc je refute ces arguments

Tu veux dire que jamais personne autour de toi ne fait d'erreurs dues à la fatigue ou à l'inattention temporaire ? Je t'assure que tu es statistiquement une exception très rare alors. La majorité des erreurs sont dues à des inattentions. Et ils sont en général vite corrigé grâce à la compilation. Rien de grave donc.

[Thierry Chappuis]

L'argument de l'effet documentaire du cast est le seul qui me parle (un peu).

Thierry

[corrector]

Non, l'autre argument est que c'est inutile, et un troisième est que ça a l'avantage de ne pas compiler en C++.

Tu parles sérieusement?

[Médinoc]

Oui.
Si je veux qu'un code puisse compiler aussi bien en C qu'en C++, je le conçois exprès pour ça et j'utilise pas mal de macros (notamment pour les casts).

[Médinoc]

Dans ce cas, je ne comprends pas la question. Peux-tu l'expliciter ?

[Jean-Marc.Bourguet]

Dans ce cas, je ne comprends pas la question. Peux-tu l'expliciter ?

Pourquoi vouloir volontairement que quelque chose ne compile pas en C++?

(Sur le sujet, je ne caste pas le resultat de malloc en C parce que c'est idiomatique, mais c'est la seule raison et je continue a trouver que la convertion implicite de void* en T* est une horreur.)

[Médinoc]

OK, je comprends la question maintenant. Eh bien, c'est partiellement par idéologie (C et C++ sont des langages différents), et partiellement par paresse (si je décide dès le début que mon prog ne compilera pas en C++, je n'ai pas à me soucier des différences plus subtiles).

Edit: Et aussi parce que je n'aime pas les casts C-Style et j'essaie de les éviter quand c'est possible. D'où mon emploi, quand je veux du compatible, de macros comme void_cast(type,p), qui donne juste p en C et un static_cast<> en C++...

[souviron34]

oui je dois dire pas mal d'accord avec Jean-Marc et Vicenzo....

Et je réitère : nous sommes en C. Que viennent faire des considérations sur C++ ici ???