Caster ou pas le retour de malloc

et j'ajouterais que, meme si c'est peut-etre inutile, la remarque de Jean-Marc est tout a fait correcte, en particulier pour des gros codes : l'aspect documentaire est important....

M'enfin tout ce debat est apparu purement parce que ca me choquait un peu de voir a chaque fois dit systematiquement "on ne caste pas le retour de malloc"....

Et que l'aspect "dangerosite" est totalement negligeable...

Donc cette position "de principe" m'apparaissait juste comme un tantinet "ayaotellesque" ;) (et denuee de fondement)

Tu oublies que de toute façon, "On n'utilise pas de cast C-style en C++" non plus. :P

Donc, caster le retour de malloc() est une mauvaise pratique à la fois en C et en C++.:aie:

Entre entiers et flottants, peut-être, mais c'est le static_cast qui est recommandé.
Entre pointeurs, c'est vraiment déconseillé (et de pointeur à flottant, n'en parlons pas...)

Citation:

---

Envoyé par Médinoc

Tu oublies que de toute façon, "On n'utilise pas de cast C-style en C++" non plus. :P

Donc, caster le retour de malloc() est une mauvaise pratique à la fois en C et en C++.:aie:

---

je n'oublie pas, je m'en fiche royalement :P

je suis en C, je programme en C, et je me contrefiche de ce qui se passe en C++...

Citation:

---

Envoyé par Médinoc

Entre entiers et flottants, peut-être, mais c'est le static_cast qui est recommandé.
Entre pointeurs, c'est vraiment déconseillé (et de pointeur à flottant, n'en parlons pas...)

---

Justement, il n'existe pas de cast de pointeur à flottant, en C ou en C++.

Donc, quand on écrit :

Code:

---

double d = (double) foo();

---

foo() ne peut pas être de type pointeur, c'est forcément un type numérique.

Tant mieux.

Citation:

---

Envoyé par Médinoc

Tu oublies que de toute façon, "On n'utilise pas de cast C-style en C++" non plus.

---

Juste pour faire l'avocat du diable : Pourtant C++ autorise les "cast C-style"

Citation:

---

Envoyé par souviron34

bah plein de cas, dès que tu as par exemple une structure d'un certain type, même en la passant comme pointeur, et que tu passes une structure équivalente, mais d'un autre nom que celui utilisé dans la déclaration du prototype...

---

Ca dépend de 'équivalente'

• Si c'est 'identique', pourquoi 2 noms différents ? Ou alors utiliser un alias (typedef)...
• Si c'est 'compatible', ça demande à être vérifié et là, oui, le cast est indispensable.

Citation:

---

Ou une variable short que tu veux passer à une fonction attendant un int, etc etc....

Un compilateur bien réglé te jettera si tu ne mets pas de cast...

---

Dans ce cas précis, non. Le short est promu silencieusement en int et basta.

Citation:

---

Et donc, si je suis ce que vous dites, il faut déconseiller l'usage du cast, mais il sera demandé dans certaines conditions :aie: pas évident comme notion quand on débute...

---

On utilise pas de cast, sauf si c'est requis. C'est tout et c'est simple.

Citation:

---

Et quand on ne débute plus, ben l'inconvénient cité n'est plus important, car on sait ce qu'on fait..

---

Mais pourquoi écrire du code inutile et qui complique la maintenance ? Personnellement, j'ai autre chose à faire... On peut aussi doubler les parenthèses

Code:

---

if ((p != NULL))

---

... des fois qu'y en ait une qui pète...

Citation:

---

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

typedef struct pPere { int age ; int nb_Enfs ; char *Nom ; } Pere ;   typedef struct pFils { int age ; int nb_Enfs ; char *Nom ; } Fils ;

---

---

Si deux mêmes structures ont des noms différents, il y a un problème d'analyse des données...

Code:

---

1 2 3 4 5 6 7 8 9 10

typedef struct { int age ; int nb_Enfs ; char *Nom ; } personne ;   <...>   personne pere; personne fils;

---

rien de sorcier et aucun cast n'est requis.

Citation:

---

Envoyé par souviron34

pas dans un passage de fonction, si la déclaration du prototype attend un int...

---

Ben si...

Citation:

---

Envoyé par souviron34

peut-être que cela marche pour short <-> int (je n'en suis pas certain cependant, car je travaille sur des codes où c'est casté et si on enlève le cast le compilo gueule),

---

Tu es certain que tu compiles en C et non en C++ ?
Tu es certain qu'il s'agit de short et non de short * ?

Citation:

---

mais en tous cas avec les exemples donnés plus haut, dès qu'il y a structure ou autre, il faut caster...

---

Dès qu'il y a un pointeur autre que void*, une vérification est faite par la plupart des compilateurs (mais elle n'est pas exigée par le langage C).

Citation:

---

Envoyé par souviron34

que ce soit dans C99, ok.

Mais par exemple dans K&R :

---

Dans la première édition du K&R, il n'est pas question de void ni de void*. Le type retourné par malloc() était char*, et était donc obligatoire de faire un cast explicite.

Depuis la publication de la norme et la sortie de la 2ème édition, le cast n'est plus obligatoire suite à la création du type void et à la modification du type retour né par malloc() en void*. Malheureusement, certains exemples du K&R 1 sont restés tels quels dans le K&R 2. Les auteurs ont publié un errata :

http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html

Citation:

---

Envoyé par 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.

---

Citation:

---

Envoyé par souviron34

mais avec ceci :

---

En tout cas, pas avec gcc :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Project : Forums Compiler : GNU GCC Compiler (called directly) Directory : C:\dev\forums\ -------------------------------------------------------------------------------- Switching to target: default Compiling: main.c main.c:1: warning: unused parameter 'param' Linking console executable: console.exe Process terminated with status 0 (0 minutes, 0 seconds) 0 errors, 1 warnings

---

Citation:

---

Envoyé par corrector

Parce que ça aurai fait une différence? Dans quel cas?

---

Je suppose que le C++ utilisant le principe de la surcharge, le type du paramètre sert à différencier les fonctions... Il n'y a donc pas de promotion comme en C, et si les types de corresponde nt pas, ça doit râler...

Citation:

---

Pardon? Un exemple?

---

Si je reprends l'exemple de Souviron, mais avec des pointeurs :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

void toto (int *param) { }   void toto1 (void) { short s;   toto (&s); }   int main (void) { toto1 (); return 0; }

---

Ca donne (gcc):

Code:

---

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

Project : Forums Compiler : GNU GCC Compiler (called directly) Directory : C:\dev\forums\ -------------------------------------------------------------------------------- Switching to target: default Compiling: main.c main.c:1: warning: unused parameter 'param' main.c: In function `toto1': main.c:9: warning: passing arg 1 of `toto' from incompatible pointer type Linking console executable: console.exe Process terminated with status 0 (0 minutes, 0 seconds) 0 errors, 2 warnings

---

ce qui se comprend parfaitement, car c'est une erreur de codage entrainant un comportement indéterminé.

Citation:

---

Envoyé par Jean-Marc.Bourguet

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

---

Je ne vois pas bien en quoi ça aide à la compréhension du code.

Code:

---

T *p = malloc (sizeof *p * n);

---

est suffisamment clair, non ?

De plus, ça entraine de la maintenance supplémentaire en cas de changement de type, ce qui n'est pas le code que j'ai posté juste au-dessus...

Citation:

---

Envoyé par Emmanuel Delahaye

Je suppose que le C++ utilisant le principe de la surcharge, le type du paramètre sert à différencier les fonctions... Il n'y a donc pas de promotion comme en C, et si les types ne correspondent pas, ça doit râler...

---

Peut-être pas exactement "comme en C", mais il y a des "integral promotions" et des "integral conversions".

Citation:

---

Envoyé par vicenzo

* 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é.

---

Pendant mes 17 ans de programmation dans l'industrie, j'en ai vu des vertes et des pas mures...

Dans les PME que j'ai connu, c'est la jungle totale, tout le monde se mêle de tout, fait n'importe quoi et se bombarde programmeur du jour au lendemain.

Des appels dans fonctions sans prototypes, invisibles par ce qu'on avait désactivé les options de compilations, ça fait partie des choses que j'ai pu constaté...

Activation des warnings : 5000 warnings !

Ensuite, on passe des heures à créer des headers, à corriger des appels de fonctions erronés (erreur de type, manque un paramètre etc.) ... Il ne fat faire aucune hypothèse simplificatrice. En gros, (théorie du chaos), tout ce qui peut arriver finit un jour par arriver. L'oubli de <stdlib.h> en fait partie.

J'ose espérer que les services de développement logiciels des grosses boites sont mieux organisés (ce que j'ai vu à la SAT, par exemple était correct).

Citation:

---

Envoyé par Emmanuel Delahaye

Tu es certain qu'il s'agit de short et non de short * ?

---

Citation:

---

Envoyé par Emmanuel Delahaye

Si je reprend l'exemple de Souviron, mais avec des pointeurs :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

void toto (int *param) { }   void toto1 (void) { short s;   toto (&s); }   int main (void) { toto1 (); return 0; }

---

Ca donne (gcc):

Code:

---

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

Project : Forums Compiler : GNU GCC Compiler (called directly) Directory : C:\dev\forums\ -------------------------------------------------------------------------------- Switching to target: default Compiling: main.c main.c:1: warning: unused parameter 'param' main.c: In function `toto1': main.c:9: warning: passing arg 1 of `toto' from incompatible pointer type Linking console executable: console.exe Process terminated with status 0 (0 minutes, 0 seconds) 0 errors, 2 warnings

---

ce qui se comprend parfaitement, car c'est une erreur de codage entrainant un comportement indéterminé.

---

oui c'est ce que je voulais dire...

Mais c'est pour ca que je maintient que, comme la notion de cast est cependant indispensable a connaitre, et que il y a peu de code comme tu l'ecris :

Code:

---

1 2	T *p = malloc (sizeof *p * n);

---

et que la plupart du temps (95% mini) c'est plutot :

Code:

---

1 2	p = malloc (sizeof *p * n);

---

il peut etre judicieux d'ecrire pour memoire :

Code:

---

1 2	p = (T *) malloc (sizeof *p * n);

---

pour se rememorer (surtout avec un nom de variable aussi explicite :roll:) que c'est bien du type T*.

Miantenant, comme je le disais au debut, je m'en fiche un peu, mais c'est juste que je ne vois pas le point de le deconseiller aussi fort que cela l'est ici regulierement...

Et que, comme dit ci-dessus et comme le disent Jean-Marc et corrector, cela peut avoir un effet documentaire....

Et que les arguments de "dangerosite" sont absurdes pour tout projet normalement geres en C (j'en ai encore parle autour de moi aujourdhui, et tous les gens ayant de la bouteille en C ont tous travaille avec des "commonC.h" contenant la plupart des entetes standards, que ce soit dans l'aviation, l'embarque, la simulation, ou la reconnaissance de la parole. Je l'avais aussi en meteo, et en medical, et en systemes experts)

Note: je viens de voir que tu parles de PME.. De ce cote-la je ne connais pas, mais dans l'industrie lourde, je n'ai jamais vu ca...

Citation:

---

Envoyé par souviron34

Note: je viens de voir que tu parles de PME.. De ce cote-la je ne connais pas, mais dans l'industrie lourde, je n'ai jamais vu ca...

---

Et je crois que toute la différence est là...

Citation:

---

Envoyé par Emmanuel Delahaye

Et je crois que toute la différence est là...

---

sans doute..

Mais a ce compte-la, il faut plutot conseiller de regler correctement son compilo et de se faire justement un "CommonC.h", plutot que de deconseiller l'usage de quelque chose d'inoffensif (puisque ce n'est pas necessaire), voire de benefique en ce qui concerne la lisibilite et maintenance ulterieure..

Citation:

---

Envoyé par corrector

Bien sûr, que les casts sont indispensables en C : quand on a besoin de la division flottante de deux entiers, on fait comment?

---

Oui, c'est utile dans ce cas, si on ne peut pas faire autrement (types corrects, constantes avec . ou f )

Citation:

---

Et pour utiliser qsort?

---

Je m'en passe très bien...

http://emmanuel-delahaye.developpez.com/qsort.htm

Citation:

---

Envoyé par Emmanuel Delahaye

Oui, il est plus simple et plus lisible.

Et pour répondre à ta prochaine question, je fais toute confiance au compilateur pour supprimer les pointeurs intermédiaires si il le juge utile...

Seul le langage assembleur est fait pour écrire du code machine. Un langage de haut niveau (fusse-t-il le C) n'est là que pour expliquer l'intention du programmeur au compilateur. C'est le compilateur qui écrit le code machine...

---

Oui et ?

Code:

---

1 2 3 4

typedef struct ps { int ival ; double val ; } mastruct ;

---

Je ne suis pas certain que l'ecriture :

Code:

---

1 2 3 4 5 6 7 8

static int compare (void const *a, void const *b) { mastruct const *ms1 = a; mastruct const *ms2 = b;   if ( ms1->ival > ms2->ival ) ... }

---

soit plus claire et comprehensible que :

Code:

---

1 2 3 4 5 6 7 8

static int compare (void const *a, void const *b) { mastruct const *ms1 = (mastruct *)a; mastruct const *ms2 = (mastruct *)b;   if ( ms1->ival > ms2->ival ) ... }

---

D'autant plus si la structure contient elle-meme une structure pointee par un void* qu'il faut caster...

Citation:

---

Envoyé par Emmanuel Delahaye

Oui, c'est utile dans ce cas, si on ne peut pas faire autrement (types corrects, constantes avec . ou f )

---

Puisque qu'on en est à éliminer les casts au prix de variables intermédiaires :

Code:

---

1 2 3 4

double div (int a, int b) { double af = a; return af / b; }

---

Je t'avoue que je ne vois pas l'avantage sur :

Code:

---

1 2 3

double div (int a, int b) { return (double)a / b; }

---

mais : un cast en moins!

Citation:

---

Envoyé par corrector

Puisque qu'on en est à éliminer les casts au prix de variables intermédiaires :

Code:

---

1 2 3 4

double div (int a, int b) { double af = a; return af / b; }

---

un cast en moins!

---

Oui, pourquoi ne pas envisager cette solution...

Pour les pointeurs, par soucis de const-correctness: Quand les warnings sont activés un cast implicite ne peut pas supprimer un "const" sans que le compilo s'en aperçoive. Un cast explicite le peut.

Code:

---

1 2 3 4 5 6 7

int sortCallback(const void *pva, const void *pvb) { struct uneStructure *pa = (struct uneStructure *)pva; /*pas de warning*/ struct uneStructure *pb = (struct uneStructure *)pvb; /*pas de warning*/   /* Et hop, je n'ai plus qu'à appeler des fonctions dont j'ai oublié qu'elles modifiaient l'objet...*/ }

---

Citation:

---

Envoyé par Médinoc

Pour les pointeurs, par soucis de const-correctness:

---

Oui, pour les pointeurs. (D'où "static_cast" en C++.)

Mais, pour flottants, dirais-tu la même chose (voir mon exemple ci-dessus)?

J'avoue que je ne suis pas sûr. Peut-être le ferais-je par habitude, peut-être que je casterais, ou peut-être que je multiplierais simplement par 1.0 avant.

Citation:

---

Envoyé par corrector

Parce que ça introduit une variable pour rien et que c'est lourd?

---

De toute manière, dans les deux cas, le code généré (avec -O2) est strictement identique avec mon gcc (je sais, tu as dis que tu t'en foutais!):

Code:

---

1 2 3 4 5 6 7 8 9

div: pushl %ebp movl %esp, %ebp fildl 8(%ebp) fildl 12(%ebp) popl %ebp fdivrp %st, %st(1) ret

---

Thierry

Je croyais que le fait que ne pas caster malloc avait un intérêt pédagogique devait clore le sujet mais visiblement ça continue. On peut mettre des cast partout si on veut mais cela signifie qu'on ne sait pas quand un cast est utile et quand il ne l'est pas mais surtout quand il est dangereux.

Cast inutile :

Code:

---

char * p = malloc(100); /* malloc retourne void *, inutile de mettre un cast */

---

Cast utile :

Code:

---

1 2	double A[4][4]; double * t = (double *)A;

---

Cast dangereux :

Code:

---

char * p = (char *)1; /* en espérant obtenir p = "1" ... */

---

Citation:

---

Envoyé par corrector

Heu... c'était censé être ironique; ça signifie que si on persiste à ne pas utiliser le compilateur pour vérifier qu'on a déclaré les fonctions qu'on appelle, la seule alternative fiable de ne plus utiliser que des fonctions qui renvoient un pointeur, et d'utiliser cette valeur de retour pour initialiser un pointeur, comme ça on est sûr de détecter les problèmes de déclarations.

Voilà exactement ce que je voulais dire.

---

Je tiens à rappeler qu'en C90, c'est à priori légal d'appeler une fonction sans avoir déclaré de prototype (même si c'est une pratique horrible). Dans ce cas, le compilateur suppose que la fonction renvoit un entier de type int et ne fait aucune supposition sur le type et le nombre des arguments renvoyés.

Le compilateur n'a PAS l'obligation d'afficher un avertissement au cas ou une fonction n'est pas déclarée. Il n'a pas non plus l'obligation de proposer une option pour activer ce type d'avertissements. gcc le fait, sans doute de cl.exe le fait, mais il y a d'autre compilateurs. Par contre, en cas de conversion int vers pointeur, pour recentrer le débât le débât sur le cast de la valeur retournée par malloc() (je rapelle que c'est l'objet de ce débat. Personne ne nie que dans certains contextes, le cast est nécessaire), l'erreur de compilation est imposée (si je ne me trompe pas).

Thierry

Citation:

---

Envoyé par Melem

Cast utile :

Code:

---

1 2	double A[4][4]; double * t = (double *)A;

---

---

:sm: Non! Quelle utilité? C'est justement ce genre d horreurs qu'il faut à tout prix éviter. Ca n'a aucun sens de caster un tableau de 4 tableaux de 4 double en un pointeur sur double. (Je me demande d'ailleurs si ce comportement est défini?)

Citation:

---

Envoyé par Melem

Code:

---

char * p = (char *)1; /* en espérant obtenir p = "1" ... */

---

---

Clairement, comportement indéfini!

Thierry

Citation:

---

Envoyé par souviron34

il peut etre judicieux d'ecrire pour memoire :

Code:

---

1 2	p = (T *) malloc (sizeof *p * n);

---

pour se rememorer (surtout avec un nom de variable aussi explicite :roll:) que c'est bien du type T*.

Miantenant, comme je le disais au debut, je m'en fiche un peu, mais c'est juste que je ne vois pas le point de le deconseiller aussi fort que cela l'est ici regulierement...

---

Vu comme ça, pourquoi n'écris-tu pas:

Code:

---

1 2 3 4 5 6

int n = 10; int m;   /*...*/   m = (int) n;

---

Thierry

Le coup du tableau peut parfaitement se faire sans cast:

Code:

---

1 2	double A[4][4]; double * t = &(A[0][0]);

---

PS: Les parenthèses sont peut-être même inutiles.

Bon, 7 pages à lire c'est énorme et je vais m'y mettre. Mais juste une petite question que je pose à ceux qui défendent avec force le cast du malloc(), est-ce qu'ils pensent aussi à caster printf() en void quand ils l'utilisent ? 8-)

Moi aussi je castais malloc à mes débuts du C. Normal, à cette époque malloc renvoyait un char* et donc je comprends cette habitude mais aujourd'hui, vu qu'il renvoie un pointeur qui colle à tout ben je me fais plus c... et pour le reste je ne caste que quand c'est nécessaire.
Mais bon, ce n'est pas pour ça que je vais aussi dire que "il ne faut pas". Les programmeurs sont de grands garçons, si certains préfèrent caster malloc en connaissance de cause ben c'est aussi leur droit. Après tout, quand le C a été écrit, sa philosophie était "le programmeur sait ce qu'il fait".

[edit]
Bon, j'ai lu les 7 pages où j'ai trouvé de bons arguments dans tous les sens. Mais je crois que la meilleure phrase est celle-ci

Citation:

---

Envoyé par souviron34

...en tous cas moi) ne defend pas le "pour", mais suis contre le "contre" :D

---

Ce qui, je crois, devrais réunir tout le monde. Après-tout, on est tous des programmeurs qui aimons le C (en fait moi je l'aime moins depuis que j'ai découvert Python mais c'est une autre histoire) et l'important est d'être conscient de ce qu'on fait. Si le cast existe c'est aussi pour une bonne raison, si certains veulent en mettre un peu plus qu'il n'en faut ben ils ont aussi le droit mais si d'autres n'en veulent pas ben idem.

Citation:

---

Envoyé par Thierry Chappuis

C'est justement ce genre d horreurs qu'il faut à tout prix éviter. Ca n'a aucun sens de caster un tableau de 4 tableaux de 4 double en un pointeur sur double. (Je me demande d'ailleurs si ce comportement est défini?)

---

Ce n'est pas pour faire la dure tête mais pourrais-tu me donner une référence qui l'interdise ? Parce que je fais ça presque tous les jours ...

Citation:

---

Envoyé par Melem

Ce n'est pas pour faire la dure tête mais pourrais-tu me donner une référence qui l'interdise ? Parce que je fais ça presque tous les jours ...

---

Le type est différent. D'ailleurs, le compilateur le signale si il est réglé correctement. Par contre, ceci est correct :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#include <stdio.h>   int main (void) { double A[4][4] = { {1.1, 1.2, 1.3, 1.4}, {2.1, 2.2, 2.3, 2.4}, {3.1, 3.2, 3.3, 3.4}, {4.1, 4.2, 4.3, 4.4}, }; double *t = *A; size_t i; for (i = 0; i < sizeof A / sizeof **A; i++) { printf ("%g\n", t[i]); }   return 0; }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

1.1 1.2 1.3 1.4 2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 4.1 4.2 4.3 4.4   Press ENTER to continue.

---

parce que le les adresses des éléments d'un tableau statique sont garanties d'être consécutives, indépendamment du nombre de dimensions.

Citation:

---

Envoyé par Sve@r

Mais juste une petite question que je pose à ceux qui défendent avec force le cast du malloc(), est-ce qu'ils pensent aussi à caster printf() en void quand ils l'utilisent ? 8-)

---

Je n'en vois pas l'intérêt. Pour malloc, le cast peut servir pour écrire du code C qui soit aussi du C++ correct. L'argument de la documentation du code a été mentionné.

Mais pour printf? Qu'est-ce qu'un cast en void peut bien documenter? Quel avantage?

Citation:

---

Envoyé par corrector

Je n'en vois pas l'intérêt. Pour malloc, le cast peut servir pour écrire du code C qui soit aussi du C++ correct. L'argument de la documentation du code a été mentionné.

---

Si tu décides de te limiter volontairement, pour une raison qui t'appartient, au sous-ensemble (!= C90) commun entre C et C++, c'est ton choix. Je ne comprends toutefois pas l'intérêt de compiler du code C avec un compilateur C++, étant donné qu'il est possible (avec quelques précautions) de lier un fichier objet écrit en C et compilé à l'aide d'un compilateur C à un programme C++. J'ose espérer que, pour toi, le concept de code réutilisable n'est pas synonyme de copier-coller, non?

Citation:

---

Envoyé par corrector

Mais pour printf? Qu'est-ce qu'un cast en void peut bien documenter? Quel avantage?

---

Code:

---

(void) printf("Bonjour dvp.com!\n");

---

Dans la logique de ce qui a été avancé plus haut, ce code documente le fait que la valeur de retour de printf() ne nous intéresse pas.

Thierry

Citation:

---

Envoyé par corrector

Pour malloc, le cast peut servir pour écrire du code C qui soit aussi du C++ correct.

---

Et ça sert à quoi ? Y'a pas un opérateur 'new' en C++ ?

Un doute m'assaille ... Tu ne veux quand même pas compiler du code C avec un compilateur C++ ? Si oui, pourquoi pas en Java ou en C#, sous prétexte que ça se ressemble... Je rappelle que le C++ n'est pas un sur-ensemble du C (alors que Objective-C est un sur-ensemble, au moins de C90).

http://david.tribble.com/text/cdiffs.htm

Citation:

---

Envoyé par corrector

Le code en question était :

Code:

---

1 2	double A[4][4]; double * t = (double *)A;

---

avec le cast.

---

Bah pourquoi écrire du code incorrect, (oui, le cast masque silencieusement le défaut, c'est pas un scoop) alors qu'il suffit d'écrire du code correct :

Code:

---

1 2	double A[4][4]; double * t = *A;

---

Moins il y a de cast, mieux je me porte...

Citation:

---

Envoyé par Emmanuel Delahaye

alors qu'il suffit d'écrire du code correct :

Code:

---

1 2	double A[4][4]; double * t = *A;

---

Moins il y a de cast, mieux je me porte...

---

Justement, ce code est-il correct (en supposant que tu utilises t pour indexer 16 éléments, pas 4)?