Bonsoir,

Citation Envoyé par Patriarch24
Les avantages principaux d'utiliser const sont :

-- la valeur est typée
Mouais...c'est le cas des variables en C, const ou pas...
C'est comme si tu me disais "les voitures à trois roues sont des véhicules" : certes, mais cela n'a aucun rapport avec le fait qu'elles aient trois roues ou pas.

Citation Envoyé par Patriarch24
-- on peut définir des constantes locales (à portée réduite)
exemple :
struct tab{
const int size = 256;
int toto[size];
};
Evidemment, l'exemple est bidon, mais tu vois ce que je veux dire...
Ben justement, non je ne vois pas: c'est bien le problème.

Citation Envoyé par Patriarch24
NEANMOINS, si le compilateur est suffisamment "intelligent"
Comme tu le dis, le code est le meme. Optimisation = 0.
Là, tu généralises. Je n'ai pas dit que le code était le même. J'ai dit que le code pourrait être (!="est") le même SI le compilateur était suffisamment "intelligent" pour détecter que l'adresse d'un "const" n'était jamais utilisée. La nuance peut avoir son importance.

Citation Envoyé par Patriarch24
register char c;
register ? Cela fait bien longtemps que les processeurs snt suffisamment rapides pour n'avoir pas à utiliser ce mot clé.
Ah... Je l'attendais celle-là...
Premièrement, l'utilisation de "register" n'a pas de rapport direct avec la rapidité/lenteur supposée d'un processeur [1]. Pour preuve, tu peux même rendre un programme plus lent en utilisant mal ce mot clé.
"register" permet de demander au compilateur de bien vouloir, si possible, faire en sorte qu'une variable soit stockée dans un registre et cela peut permettre de garantir certaines propriétés du code généré qui ne le seraient pas forcément si on laissait le compilateur décider pour nous.
Ce n'est pas parce qu'un prof' t'a dit un jour, pour simplifier son discours, de ne pas t'occuper de "register" quand tu lui as demandé à quoi cela servait que c'est une directive inutile.
Maintenant, si tu crois dur comme fer que son utilisation est inutile, je t'engage très vivement à prendre contact avec les développeurs du noyau et des pilotes de périphériques de Linux (pour ne citer que ce système) et de la GNU/libc : tu vas sûrement leur apprendre quelque-chose. Quelques exemples :
- http://fxr.watson.org/fxr/source//dr...2.6.11.8#L1154 ;
- http://fxr.watson.org/fxr/source//dr...x-2.6.11.8#L33 ;
- http://fxr.watson.org/fxr/source//dr...-2.6.11.8#L149 ;
- http://fxr.watson.org/fxr/source//fs...x-2.6.11.8#L82 ;
- http://fxr.watson.org/fxr/source//ar...ux-2.6.11.8#L6 ;
- http://fxr.watson.org/fxr/source//in...x-2.6.11.8#L75 (x86-64, c'est assez récent comme processeur ?) ;
- etc, etc, etc...

Citation Envoyé par Patriarch24
Dans le second (cas), une zone de mémoire initialisée est utilisée ET on récupère l'adresse de cette zone ET on va lire à cette adresse.
Je te le rappelle qu'une constante a une adresse définie à la compilation,
Non, une constante n'a pas d'adresse. Elle a une valeur.

Citation Envoyé par Patriarch24
et n'est pas stockée sur la pile,
Je ne vois pas le rapport avec mes exemples : où vois-tu une manipulation de la pile dans mes exemples ?

Citation Envoyé par Patriarch24
donc le compilateur peut directement connaitre la valeur contenue dans la case mémoire associée.
Si tu parles d'une constante : il n'y a pas de case mémoire associée ou, plus précisément, il n'y a pas *une* case mémoire associée puisque la valeur pourra être trouvée à plusieurs endroits dans le code.
Si tu parles d'une variable déclarée avec le mot-clé "const", il y a de grandes chances pour que beaucoup de compilateurs ne se soucient même pas de leur valeur quand ils génèrent du code : c'est son adresse qui les intéresse. La valeur n'étant utilisée que pour générer la partie "données initialisées" de l'exécutable.

Citation Envoyé par Patriarch24
Seule perte : l'instruction correspondant au chargement de la valeur dans un registre !
C'est marrant : tu écrivais un peu plus tôt "le code est le meme. Optimisation = 0" et maintenant tu me parles de "perte"... Si une des deux solutions a pour conséquence une perte par rapport à l'autre, c'est que le code n'est pas le même et qu'il y a des chances que l'une soit plus optimisée que l'autre dans certains cas.

Bon, c'est tout ? Pas d'autre argument ?
J'avoue être déçu.

Cordialement,
DS.

[1] : d'ailleurs, si ils sont si bien que ça les processeurs actuels, pourquoi plusieurs compilateurs (pour architectures IA32) génèrent-ils du code effectuant une série d'additions pour un programme en C faisant une multiplication quand on leur demande un exécutable optimisé ?