Les nouveautés du C99

http://nicolasj.developpez.com/articles/c99/

Citation:

---

Au travers de cet article, je vous propose un tour d'horizon des nouveautés du C99.

---

Vous pouvez laisser un commentaire sur cet article à la suite.

Citation:

---

Envoyé par gege2061

V-B. Les types entiers étendus
<...>
Le C99, dans le fichier d'en-tête stdint.h propose des types dont la taille est connue :

---

Il faudrait insister sur le fait que les types définissant des tailles fixes ne sont pas portables. Il n'existent que si l'architecture permet de les implémenter.

Précisions ajoutée ;)

Citation:

---

Envoyé par gege2061

Précisions ajoutée ;)

---

Attention, ma remarque ne portait sur les types de taille fixe, c'est à dire

intN_t
et
uintN_t

et faudrait être plus clair, car là, on dirait que la remarque concerne tous les nouveaux types.

Je me permet une remarque sur cet ancien article :
http://nicolasj.developpez.com/articles/c99/#LIII-C

Je ne vois pas en quoi ne pas tout déclarer au début nuirait à la lisibilité du code. Bien au contraire, ça permet de pouvoir initialiser dès le départ les variables à leur bonne valeur, et donc simplifie la logique de code (une variable n'a pas deux états successifs), évite les risques d'erreur en cas de réorganisation, et je trouve augmente la clarté, puisque voir une valeur d'initialisation d'une variable est souvent un indice supplémentaire (en plus de son nom) pour savoir quel sera son rôle dans le programme.

Citation:

---

Envoyé par JolyLoic

Je me permet une remarque sur cet ancien article :
http://nicolasj.developpez.com/articles/c99/#LIII-C

Je ne vois pas en quoi ne pas tout déclarer au début nuirait à la lisibilité du code. Bien au contraire, ça permet de pouvoir initialiser dès le départ les variables à leur bonne valeur, et donc simplifie la logique de code (une variable n'a pas deux états successifs), évite les risques d'erreur en cas de réorganisation, et je trouve augmente la clarté, puisque voir une valeur d'initialisation d'une variable est souvent un indice supplémentaire (en plus de son nom) pour savoir quel sera son rôle dans le programme.

---

Le C permet de définir précisément la portée des variables grâce à l'usage des blocs { }. Ca permet de les définir à l'endroit précis où on les utilise et donc d'éviter le recyclage sauvage (avec utilisation d'une valeur précédente erronée, par exemple).

Un compilateur bien né saura réutiliser la même zone mémoire (ou le même registre). La } indique clairement "à partir de maintenant, la zone mémoire est libre et peut être réassignée à une autre variable".

Exemple de programmation défensive :

Code:

---

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

void f(int n) { int i; for (i = 0;i < n; i++) { }   while (i < n) /* est-on certain qu'on parle du même i ? */ { }   }

---

Code:

---

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

void f(int n) { { int i; for (i = 0;i < n; i++) { } }   while (i < n) /* err : i inconnu ! */ { }   }

---

Code:

---

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

void f(int n) { { int i; for (i = 0;i < n; i++) { } }   { int i; while (i < n) /* warn : i non initialisé ! */ { } } }

---

Possibilité de code correct :

Code:

---

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

void f(int n) { { int i; for (i = 0;i < n; i++) { } }   { int i = n / 2; /* simple exemple arbitraire */ while (i < n) { /* ... */ } } }

---

C'est effectivement une autre possibilité. Qui augmente rapidement le niveau d'indentation du code, on n'a rien sans rien. J'ai plus souvent eu des problèmes à l'initialisation que des problèmes de recyclage, mais chacun son style d'écriture.

Mon point n'était pas de dire qu'initialiser une variable au beau milieu d'un bloc était la meilleure façon de faire et la seule valide, juste de dire que la qualifier de "peu lisible" sans argumentation ni proposition d'alternatives me semblait un peu court...

Citation:

---

Envoyé par JolyLoic

C'est effectivement une autre possibilité. Qui augmente rapidement le niveau d'indentation du code, on n'a rien sans rien. J'ai plus souvent eu des problèmes à l'initialisation que des problèmes de recyclage, mais chacun son style d'écriture.

Mon point n'était pas de dire qu'initialiser une variable au beau milieu d'un bloc était la meilleure façon de faire et la seule valide, juste de dire que la qualifier de "peu lisible" sans argumentation ni proposition d'alternatives me semblait un peu court...

---

En fait, je crois qu'on est d'accord, mais j'ai du mal à te comprendre, parce que tu utilises pas mal de négations successives, et je m'y perds...

Je vais tenter de formuler plus positivement :
1 - On peut tout déclarer au début des blocs existant "naturellement"
2 - On peut ne déclarer qu'au moment où on sait comment initialiser
3 - On peut créer des blocs supplémentaires dans l'unique objectif restreindre la portée d'une variable, et déclarer au début de ces blocs

A mon avis, 2 et 3 sont tous deux meilleurs que 1. Entre 2 et 3, je n'ai pas de préférence particulière, mon choix dépendra de la situation.

Le document critique, sans vraiment argumenter, le choix 2, mais sans mentionner 3. Ce qui fait qu'il va inciter l'utilisateur peu experts à utiliser 1, ce qui me gêne.

J'espère avoir clarifié mon propos.

Oui, comme ça, ça me va. En fait, c'est le point 2 qui conditionne le codage.