Discussion :

[Emmanuel Delahaye]

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

http://cjoint.com/?cnpKxor2Qp

Wouah ! Le vieux scan ! Ta version du K&R est complètement dépassée (original : 1978)!

Je rappelle que le K&R2 qui correspond aux drafts de C89 (C8x) est sorti en 1988. Complété de son errata, c'est le livre de référence qui correspond à l'immense majorité du C utilisé actuellement. Le C K&R (ou pré-ANSI) est conservé pour la maintenance des anciens programmes, mais il est poubellisé au fur et à mesure qu'il est remplacé par du C89 (ANSI) / C90 (ISO), voire C99 de nos jours.

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

OK, sur les implémentations non conformes à C89 (aka pré-ANSI), il peut y avoir des problèmes avec free(NULL). (personnellement, en principe, je n'appelle pas free(NULL), perte de temps).

[souviron34]

il n'empêche que 3 choses en ressortent, qui sont toujours valables :

1) pour être indépendant de la machine, vaut mieux faire les cast sur des pointeurs (pour mémoire certaines machines (Harris, et Bull) étaient 36 et 42bits...). Rien ne garanti que l'on n'aura pas un des ces jours un tordu de la même manière.

2) pour les sizeof, il est conseillé de le faire sur le type et non sur la variable..

3) et donc la notation que je suis pour les cast n'est pas une absurdité. Peut-être pas ce qui est enseigné de nos jours, certes, mais un maçon, quelque soit la nature du ciment qu'il utilise (précontraint, standard, colle, ciré, etc..) sait toujours faire une maison ;-)

[hegros]

2) pour les sizeof, il est conseillé de le faire sur le type et non sur la variable..

Quelle différence ? Faire un sizeof sur la variable c'est le faire sur le type l'inverse par contre n'est pas vrai.

On peut savoir d'ou tu tiens ce conseil ? Une référence un exemple parlant concret ?

[Médinoc]

Le seul exemple que je verrais, c'est le risque de prendre l'habitude de faire sizeof() sur un tableau et tomber ensuite dans le piège en le faisant sur un pointeur.
Problème solvable en C++, mais pas en C.

[Emmanuel Delahaye]

il n'empêche que 3 choses en ressortent, qui sont toujours valables :

1) pour être indépendant de la machine, vaut mieux faire les cast sur des pointeurs (pour mémoire certaines machines (Harris, et Bull) étaient 36 et 42bits...). Rien ne garanti que l'on n'aura pas un des ces jours un tordu de la même manière.

Pourquoi ? Si le type est pointeur sur objet, à quoi peut bien servir le cast, sachant que malloc() retourne un void * ?

Code :

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

T *p = malloc(123);

est garanti de fonctionner sur n'importe quelle machine implémentant le langage C. C'est le compilateur qui fait génère le code qui les ajustements nécessaires. Je rappelle que chaque machine a son(ou ses) compilateur(s), même si il a le même nom partout comme gcc ...

2) pour les sizeof, il est conseillé de le faire sur le type et non sur la variable..

Je ne vois pas du tout pourquoi. Le langage C dit que c'est strictement équivalent, étant donné que la variable a le même type. C'est une question de style et nous sommes nombreux à penser que le style qui facilite la maintenance est préférable. La petite difficulté de lecture du début s'estompe très rapidement...

3) et donc la notation que je suis pour les cast n'est pas une absurdité.

Elle a eu sa raison d'être avant l'invention du void (C89), car malloc() retournait (char *), mais s'accrocher à cette vielle lune, même moi qui ait commencé le C et 1988, je ne le fais pas !

Quand j'ai commencé à trainer mes bottes sur news:comp.lang.c dans les années 1999, j'avais 11 ans de C autodidacte derrière moi et je me croyais le roi du monde.

J'ai vite compris que d'autres avaient réfléchi à tout ça de puis bien plus longtemps que moi et proposaient des facilités de codage tout à fait légales et portables. C'est là que j'ai commencé à véritablement apprendre le langage C. D'ailleurs, la fine équipe de c.l.c, sous la responsabilité de Richard Heathfield, éminent contributeur, a fini par pondre un ouvrage tout à fait remarquable : C-Unleashed, qui est sans aucun doute le meilleur livre de C qui existe, puisque écrit par la communauté de haut niveau du langage C, florilège de contributeurs historiques, Ritchie, Stallman, membres du comité de normalisation, utilisateurs éclairés etc. Que du beau monde.

(Je rappelle que clc est un des plus ancien des forums Usenet, et qu'il a été créé à l'époque d'Arpanet, l'ancêtre d'Internet.)

Peut-être pas ce qui est enseigné de nos jours, certes, mais un maçon, quelque soit la nature du ciment qu'il utilise (précontraint, standard, colle, ciré, etc..) sait toujours faire une maison ;-)

Je fais confiance à la norme et aux implémentations 'dites' conformes (notamment gcc qui est très universel).

Mais il faut savoir débusquer les implémentations non conformes et agir en conséquence. A moins qu'on travaille sur du code 'historique' (legacy code), ça reste des cas très limités.

[Thierry Chappuis]

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

En qui concerne free(), c'est la norme C90 (extrêmement portable, car la plupart des compilateurs C l'implantent) qui stipule que free() ne fait rien lorsqu'on lui passe NULL. Si ce n'est pas le cas avec les systèmes sur lesquels tu travailles, c'est qu'ils ne sont pas conforme. A part cela, j'ouvrage K&R 2ème édition à l'annexe B5, et je trouve:

void free(void *p)
free libère l'espace mémoire pointé par p; elle ne fait rien si p vaut NULL. p doit être un pointeur sur un espace mémoire alloué par calloc, malloc ou realloc.

Je ne partage pas ton point de vue ni pour les casts, ni pour sizeof. Certes mon expériences est moindre que la tienne, mais je pense qu'il est raisonnable de faire confiance à la norme C90 lorsqu'il s'agit de programmer de manière portable.

Thierry

[souviron34]

Je fais confiance à la norme et aux implémentations 'dites' conformes (notamment gcc qui est très universel).

Pas de problèmes là.. Je vais me mettre à jour grâce à vous je ne suis qu'un vieux crouton...

Mais il faut savoir débusquer les implémentations non conformes et agir en conséquence. A moins qu'on travaille sur du code 'historique' (legacy code), ça reste des cas très limités.

Dans mon milieu de travail ça a été et la plupart du temps ça reste la norme...
(vous seriez surpris de savoir le nombre de programmes scientifiques (y compris opérationnels) datant d'il y a 15, 20, 25 ou 30 ans : la meilleure des raisons étant qu'ils ont été fait par les utilisateurs et qu'en général ils font ce qu'il doivent faire... Et j'ai même vu récemment (5 ans) le programme de modélisation des vagues dans l'Atlantique, écrit en Fortran77, où la seule modification à apporter était de le passer en Fortran90 (remplacement des fonctions obsolètes) et de le rendre parallèlle (ce qui était le plus long). Mais ce genre de programme, on le re-programme pas....)

et mujigka, en ce qui concerne le free, je suis d'accord, sauf que la deuxième partie de la phrase est beaucoup moins évidente qu'il n'y parait...

p doit être un pointeur sur un espace mémoire alloué par calloc, malloc ou realloc.

rappelez-vous vos expériences passées... ça ne vous dit rien ce genre de bugs ??

[Thierry Chappuis]

rappelez-vous vos expériences passées... ça ne vous dit rien ce genre de bugs ??

Je n'ai que peu d'expérience, donc cela ne me dit rien. Mais je suis curieux...

Thierry