Re: [certi-devel] short, long unsigned, signed int et compagnie !

[Benoît Bréholée]

Valéry Raulet <address@hidden> writes:

> Pour ce qui est du type short int et long int : c'est normalisé, l'un
> sur 16 bits et l'autre sur 32 bits.
> Pour le type int, chaque système le gère comme il veut, soit 16 bits,
> soit 32 bits.

Ce qui est normalisé c'est la relation d'ordre entre les tailles de
ces types, celles d'un short est inférieure ou égale à celle d'un int,
qui est inférieure ou égale à celle d'un long. Concernant les valeurs,
le char est la plus petite unité manipulable directement par le
processeur, le short (si c'est comme en C) doit couvrir au moins
l'intervalle équivalent à une représentation d'entier signé sur 16
bits. L'int a exactement la même définition (dans la mesure ou seul un
minimum est exigé). Pour une taille minimale du long, je ne sais
pas. Par contre l'int est aussi l'entier natif du processeur, le plus
rapide à manipuler. Donc ces valeurs (short=16, int=long=32) sont les
plus fréquentes, mais leur définition n'est pas liée à des valeurs
fixes. Sur architectures 64 bits, un int fait a priori 64 bits.

On a en fait : 
- int : le type entier « de choix » pour C++
- short : un type si possible plus petit que int
- long : un type si possible plus grand que int

> A mon avis, le mieux est de définir tous les parcours de listes,
> stockage de tailles et autres du même genre sous la forme d'un
> unsigned long int (ulong) soit 32 bits non signé.  Comme ça, c'est
> commun à toutes les implémentations et de plus le programmeur sait
> exactement que la valeur ne doit pas être négative.

- ce n'est pas commun à toutes les implémentations
- 32 bits, c'est déjà ce qu'on a la plupart du temps avec int
- mais surtout, l'int ne peut être que plus rapide, et on n'a nulle
  part besoin de repousser la valeur limite maxi de int

- pour le unsigned, sans doute pas d'influence sur la facilité de
  manipulation, mais « unsigned » c'est un pénible quand ce n'est pas
  nécessaire, et « uint » (est-ce vraiment ISO C++ au fait?) ce n'est
  pas ce qu'il y a de plus connu... L'avantage étant que le
  programmeur sait que la valeur ne doit pas être négative, pour ça je
  regarderai ce que ça donne pratiquement dans le code, est-ce que le
  unsigned pertinent n'est pas plutot à placer dans les variables et
  attributs utilisés pour les bornes ?

> Pourquoi long plutôt que short ? La plupart des machines actuelles
> sont sur 32 bits. L'alignement fait que l'on ne gagne rien en mémoire
> si on choisit des short. Par contre, pour les échanges réseaux, ça
> peut importer ! Si on est sûr de ne jamais dépasser 65535 alors 16
> bits (ushort) est suffisant.

Le processeur ne travaillera surtout jamais avec des short, mais avec
des int (même quand dans le code on les déclare en short). Donc si on
a besoin d'avoir un entier de taille minimale, et dont on sait qu'il
va tenir sur 16 bits :
- on travaille avec un int
- avant de l'utiliser là ou c'est critique, on le convertit en short,
  éventuellement après vérifications

> Qu'en penses-tu ?
> 
> Pour moi, éviter le int tout seul ;-)

Éviter le type qui par définition dans la norme est le type à
privilégier ? 

Quelques liens
http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/#objets
http://casteyde.christian.free.fr/cpp/cours/online/x241.html

Et à la lecture de fclc++ c'est ce qui ressort aussi. Je vais essayer
de trouver des discussions là-dessus, il en a forcément été question...

Benoit.