Le type de conditionnel utilisé dans une boucle peut limiter les types d'optimisations qu'un compilateur peut effectuer, pour le meilleur ou pour le pire. Par exemple, étant donné:
uint16_t n = ...;
for (uint16_t i=1; i<=n; i++)
... [loop doesn't modify i]
un compilateur pourrait supposer que la condition ci-dessus devrait entraîner la sortie de la boucle après la nième boucle de passage, à moins que n ne puisse 65535 et que la boucle puisse se terminer d'une autre manière que si i dépasse n. Si ces conditions s'appliquent, le compilateur doit générer du code qui entraînerait l'exécution de la boucle jusqu'à ce que quelque chose d'autre que la condition ci-dessus provoque sa fermeture.
Si la boucle avait plutôt été écrite comme suit:
uint16_t n = ...;
for (uint16_t ctr=0; ctr<n; ctr++)
{
uint16_t i = ctr+1;
... [loop doesn't modify ctr]
}
alors un compilateur pourrait supposer en toute sécurité que la boucle n'aurait jamais besoin de s'exécuter plus de n fois et pourrait ainsi générer du code plus efficace.
Notez que tout débordement avec des types signés peut avoir des conséquences désagréables. Donné:
int total=0;
int start,lim,mult; // Initialize values somehow...
for (int i=start; i<=lim; i++)
total+=i*mult;
Un compilateur pourrait réécrire cela comme:
int total=0;
int start,lim,mult; // Initialize values somehow...
int loop_top = lim*mult;
for (int i=start; i<=loop_top; i+=mult)
total+=i;
Une telle boucle se comporterait de manière identique à l'original si aucun débordement ne se produit dans les calculs, mais pourrait s'exécuter indéfiniment, même sur les plates-formes matérielles où le débordement d'entier aurait normalement une sémantique d'encapsulation cohérente.