Discussion :

[gege2061]

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

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.

[Emmanuel Delahaye]

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.

[gege2061]

Précisions ajoutée

[Emmanuel Delahaye]

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.

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

[Emmanuel Delahaye]

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 :

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

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 :

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

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 :

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

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
 
void f(int n)
{
   {
      int i;
      for (i = 0;i < n; i++)
      {
      }
   }
 
   {
      int i = n / 2; /* simple exemple arbitraire */
      while (i < n)
      {
         /* ... */
      }
   }
}

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

[Emmanuel Delahaye]

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

[JolyLoic]

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.

[Emmanuel Delahaye]

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