Discussion :

[nschoe]

Bonjour,

J'ai une petite question : je me pose la question de savoir pourquoi est-ce que dans une boucle for on déclare "toujours" la variable "compteur" traditionnellement nommée i en type int ?

Si lorsqu'on programme on sait pertinemment que cette variable ne dépassera pas 255 (ce qui arrive quand même assez souvent), pourquoi ne pas la déclarer en tant que char ?

J'ai lu (vraiment survolé) sur ce forum que le type int était "celui le mieux géré par les processeurs" et donc qu'il était plus rapide de déclarer un int qu'un char : est-ce que c'est vrai, est-ce que j'ai mal compris ?

Voilà, merci d'avance ^^

[koala01]

Salut,

Effectivement, les types primitifs plus petits que des int sont "promus" en int pour des raisons de facilité d'utilisation de la part du processeur.

Mais je crois qu'il y a aussi le fait que, inconsciemment, on associe souvent le type char aux... caractères et le type int aux... entiers.

Ce sont donc là deux raisons qui font que beaucoup de gens vont "naturellement" se tourner vers une variable de type int lorsqu'il s'agit de déclarer un compteur

Mais, ceci dit, n'oublie pas que "qui peut le plus peut le moins", et qu'il sera toujours préférable d'utiliser un type "qui peut représenter plus de valeur" qu'un type qui risque de ne pas pouvoir représenter toutes les valeurs que l'on souhaite utiliser

N'oublie en effet pas que les 255 valeurs possibles pour un (unsigned) char ne sont absolument pas assurées, car, pour autant qu'il est possible de représenter l'ensemble du jeu de caractères utilisé par l'architecture, le nombre de bits utilisés pour un char (et par conséquent la plage de valeurs qu'il peut représenter) ne dépend de l'architecture

L'un dans l'autre, si l'on ne considère que les caractères non accentués, les chiffres et les (32) caractères qui ont valeur d'instructions, il ne faut que 94 valeurs différentes, ce qui permettrait donc à un char d'être représenté sous la forme de ... 7 bits, mais qu'il n'est pas impossible d'envisager une architecture sur laquelle le jeu de caractères nécessiterait n'importe quel nombre de bits, supérieur à 8

[nschoe]

D'accord d'accord !

Donc en définitive, il est préférale de continuer à utiliser des int pour les boucles for ?

Le gain de performance entre un char et un int pour une boucle est négligeable ?

[loufoque]

J'ai une petite question : je me pose la question de savoir pourquoi est-ce que dans une boucle for on déclare "toujours" la variable "compteur" traditionnellement nommée i en type int ?

Traditionnellement c'est plutôt le type qui faut et non int...
Les boucles avec entiers étant généralement faites pour parcourir une séquence à accès aléatoire (ce qui n'est d'ailleurs pas une bonne idée, un itérateur est plus efficace et plus universel), on utilise le type qui est documenté comme étant suffisamment grand pour contenir la taille maximale de la séquence, typiquement size_t.
Bien sûr, il est mieux de ne pas écrire ce type de boucle du tout, et d'utiliser soit des itérateurs, soit plus pratique, une boucle foreach.

[nschoe]

Je suis d'accord avec vous sur le principe, d'ailleurs dans mes codes, j'essaie toujours de faire comme vous le préconisez, par contre, est-ce qu'il est possible de tout le temps utiliser des itérateurs, ou un foreach ... je ne saurais le dire.

[loufoque]

Ça dépend si tu es en train de faire des algorithmes intelligents et non triviaux, ou si tu veux juste parcourir une séquence qui satisfait tel critère...

[3DArchi]

Dans le pire des cas, tu as toujours l'itérateur Boost.Counting Iterator. Puis tu peux définir tes propres itérateurs selon tes besoins. Mais après, dans un contexte industrielle, il faut parfois composer avec des boucles classiques. Un int permet à ta boucle d'être gérée au mieux et à mon sens n'apporte ni risque ni ambigüité.

[nschoe]

D'accord. Merci pour les infos !

[loufoque]

Modéliser les générateurs de séquence par des input iterators c'est pas mal, oui.
Counting iterator n'est qu'un cas particulier