Envoyé par Médinoc
si ton analyse et ta conception sont bien faits, à la limite tu peux rajouter des propriétés à l'objet, mais pas son type...
![]()
Envoyé par Médinoc
si ton analyse et ta conception sont bien faits, à la limite tu peux rajouter des propriétés à l'objet, mais pas son type...
![]()
On n'est jamais à l'abri de la nouveauté.
- Il peut un jour être nécessaire de "scinder un type en deux"; voire en C++, de jouer avec l'héritage, s'apercevoir que les fonctions exposées par la classe mère sont insuffisantes pour les nouveaux besoins et qu'il faudra désormais travailler directement avec le type dérivé, etc.
- Ou bien, directement s'il est question d'un type entier, passer à un type entier plus grand;
- Ou encore partir d'un programme utilisant des char et le mettre à jour pour supporter unicode (passer aux wchar_t ou aux TCHAR sous Windows).
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Voici une question de débutant, que je suis d'ailleurs, mais en quoi le fait de caster NULL ici lui confère un type fort. Lorsqu'un écrit:Envoyé par Médinoc
Triangle *p_triangle = NULL;
On a un cast implicite (void *) -> (Triangle *) autorisé en C. Non?
Thierry
"The most important thing in the kitchen is the waste paper basket and it needs to be centrally located.", Donald Knuth
"If the only tool you have is a hammer, every problem looks like a nail.", probably Abraham Maslow
FAQ-Python FAQ-C FAQ-C++
+
Oui.Envoyé par mujigka
Le cast de NULL n'est pas obligatoire.
Mais il arrive parfois de rencontrer ce type de notation car certaines personnes y voient un interet documentaire (personellement je ne partage pas cette opinion).
J'ai egalement entendu parler, et Souviron le confirme dans son message, d'anciens compilateurs presentant des problemes de type sur NULL. Dans ce cas, le cast n'a plus de raison d'etre mais peut etre rencontre dans du code ancien ou ecrit par des personnes ayant pris cette habitude.
Pas forcément si ancien que ça....Envoyé par gl
![]()
Exemple tiré de XFree-86 :
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
26
27 XFREE86_Region XFREE86_XCreateRegion() { XFREE86_Region temp; if (! (temp = ( XFREE86_Region )Xmalloc( (unsigned) sizeof( REGION )))) return (XFREE86_Region) NULL; if (! (temp->rects = ( BOX * )Xmalloc( (unsigned) sizeof( BOX )))) { Xfree((char *) temp); return (XFREE86_Region) NULL; } .............. if (! (dstrgn->rects = (BOX *) Xrealloc((char *) dstrgn->rects, (unsigned) rgn->numRects * (sizeof(BOX))))) { ............. if ((top != bot) && (nonOverlap1Func != (void (*)())NULL)) { (* nonOverlap1Func) (newReg, r1, r1BandEnd, top, bot); }
et pour la date :
euhhh
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 Copyright 1987, 1988, 1998 The Open Group All Rights Reserved.![]()
![]()
A l'echelle de l'informatique, 10 ans (voire 20 si ce code date de 87) c'est plutot ancien (et pre-C99).Envoyé par souviron34
Et puis on peu aussi rentre dans la seconde categorie : "ou ecrit par des personnes ayant pris cette habitude.".
Sans compter sur les personnes qui trouvent une valeur documentaire a ce genre de pratique.
Oui, mais on n'a pas de cast implicite (Triangle *) -> (NimporteQuoi *)Envoyé par mujigka
![]()
Donc oui, le cast est principalement à des fins documentaires, et pour être sûr qu'on sait toujours de quoi on parle, ce qu'on passe (ou plutôt ne passe pas) à une fonction, etc.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Absolument d'accord avec la deuxième partie..Envoyé par gl
Cependant en ce qui concerne les "10 ans (voire 20 ...) etc.." , je ne suis pas d'accord.. J'ai démarré un débat sur le forum général, mais personne n'a répondu. Mais je pense que les décideurs et chefs de projets en info font un peu aussi du "jeunisme", et suivent d'un peu trop près la mode...
Je viens d'un milieu où les projets peuvent mettre 30 ans à être écrits et peuvent avoir une durée de vie de 50 ans (voir la station spatiale orbitale Freedom) : 80 000 programmeurs de 50 pays pendant 25 ans. Durée de vie prévue en orbite : minimum 40 ans. 10 ans uniquement consacré à rédiger les normes de programmation pour chaque langage.
Je respecte la pensée, et je tente de m'inscire dans la même lignée. Mon code devrait faire une fonctionalité que l'informatique peut faire mieux et plus rapidement que l'humain, le déchargeant ainsi d'une partie souvent fastidieuse de son travail. Cependant j'aime à croire que ce que je fais ne vas pas partir à la poubelle dans les 3 ans.... Mais je me fais peut-être des illusions![]()
Plus prosaiquement, pour ne citer que quelques exemples (et en remontant dans le temps) qui ont toujours leurs usages aujourd'hui :
HTTP : code C écrit en 1992
XWindow : code C écrit entre 1979 et 1984
.... : (je me souviens plus le nom là tout de suite) : bibliothèque de maths du CERN code Fortran écrit entre 1963 et 1978 (environ 20 millions de lignes)
(si ça vous intéresse je vous retrouverai le nom demain).
En résumé, oui au progrès, non à l'obscolescence (?) à tout prix....
PS: malgré tous les progrès techniques dans tous les matériaux, un ébéniste qui fait une armoire en bois, son armoire dure beaucoup plus longtemps qu'une amoire IKEA(et sans compter (je suis dans le Sud
) les acqueducs romains, un peu plus solides que les tours de la Défense...)
C'est vrai! Merci Médinoc...Envoyé par Médinoc
Thierry
"The most important thing in the kitchen is the waste paper basket and it needs to be centrally located.", Donald Knuth
"If the only tool you have is a hammer, every problem looks like a nail.", probably Abraham Maslow
FAQ-Python FAQ-C FAQ-C++
+
Pas portable. Ce nom est réservé à l'implémentation :Envoyé par souviron34
http://emmanuel-delahaye.developpez....htm#id_reserve
Selon mes regles de codage, ça donnerait ça :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11 typedef struct triangle { int s1; int s2; int s3; struct triangle *p_next; struct triangle *p_prev; } triangle_s;
Ca sert à quoi tous ces cast ?Envoyé par souviron34
D'autre part, calloc() (all-bit-to-zero) n'est pas une manière portable d'initialiser les éléments d'une structure à 0.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11 Triangle *Triangles = NULL; Triangle *elt = NULL ; Triangle *next = NULL ; ...... elt = calloc (1, sizeof(Triangle) ); if ( elt == NULL ) { if ( next != NULL )
Les casts de NULL, on en a discuté plus haut (fins documentaires, mais devrait être plus centralisé selon moi).
Celui de calloc() par contre est inapproprié.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Bah, du mauvais code ou du code écrit par des gens qui mélangent C et C++, on en trouve partout... Ca ne sert à rien de citer du code open source. C'est probablement du code qui fonctionne, mais ça n'a jamais été une référence en matière de codage. En quelques lignes :Envoyé par souviron34
- déclaration de la fonction non prototypale (manque void)
- pointeurs cachés
- définitions redondantes : XFREE86_Region est visiblement *REGION
- manque d'homogénéité : cast sans *, cast avec *...
- casts inutiles
- ! au lieu de == NULL
- affectaton dans un if()
- return multiples
je m'arrête là, parce que pour 10 lignes de code, je trouve que ça fait beaucoup...
bref, ce code ne passe pas le moindre contrôle de qualité en entreprise.
Je ne vois pas ce que ça documente. Et puis NULL est compatible avec tous les types pointeur sur objet, alors qu'est-ce que change ?Envoyé par Médinoc
Apparement si, la première allocation est bien libérée.Envoyé par Emmanuel Delahaye
Envoyé par crocodilex
Exact, c'est tellement ilisible que je ne l'avais pas vu (on va dire ça comme ça
)
Comme dit plus haut, c'est justement le problème.Envoyé par Emmanuel Delahaye
Utiliser des #define avec un NULL casté donne des NULL typés.
Bien sûr, caster directement dans chaque utilisation est stupide à mon goût...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
J'ai toujours pas compris en quoi c'était un problème. Tu peux donner un exemple de problème ?Envoyé par Médinoc
A quoi ça sert des NULL typés ? Dans un contexte pointeur, NULL a la même sémantique quelque soit le type, je ne vois pas contre quelle erreur on cherche à se défendre...Utiliser des #define avec un NULL casté donne des NULL typés.
Bien sûr, caster directement dans chaque utilisation est stupide à mon goût...
Je ne suis pas contre, mais je veux juste qu'on m'explique.
Je ne connais personnellement qu'un cas où il faut mettre un cast à NULL, c'est quand c'est un paramètre de fonction variadic, parce que dans ce cas, le contexte pointeur n'est pas implicite.
Code : Sélectionner tout - Visualiser dans une fenêtre à part printf ("%p\n", (void *) NULL);
En effet, je viens de voir la faille de mon raisonnement.
Je pensais utiliser des NULL typés pour sans cesse se rappeler qu'un paramètre à NULL était supposé être un pointeur de tel type, garder le type de variable à l'esprit en permanence, mais cela induit en fait un coût de maintenance supplémentaire si un type est modifié (comme les casts, en fait).
Donc en fait, utiliser des NULL typés est absolument inutile, mon raisonnement dessus vient de s'écrouler.
Edit : AH SI ! Je me souviens pourquoi j'avais fait ça, c'est à cause du C++, et cela évitait tout risque d'affecter un NULL à autre chose qu'un pointeur (en C, NULL est la plupart du temps (mais non-garanti) déjà un void*, alors qu'en C++, c'est généralement un bète 0). Je ne supporte pas ceux qui utilisent allègrement 0 pour NULL, voire l'inverse en C++.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
bon.. Je veux bien que C99 prenne en compte certaines choses.
Mais certaines choses sont dans la définition même de C, car MACHINE-dépendantes.
Je vous place donc ici quelques extraits de K&R pour :
- les cast
- les sizeof de variable ou de type...
Et de plus, je peux vous assurez que pour les free, si vous comptez sur le fait qu'un free(NULL) ne fera rien, eh bien bonne chance.....
http://cjoint.com/?cnpKxor2Qp
Partager