Bonsoir,
Mouais...c'est le cas des variables en C, const ou pas...Envoyé par Patriarch24
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.
Ben justement, non je ne vois pas: c'est bien le problème.Envoyé par Patriarch24
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.Envoyé par Patriarch24
Ah... Je l'attendais celle-là...Envoyé par Patriarch24
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...
Non, une constante n'a pas d'adresse. Elle a une valeur.Envoyé par Patriarch24
Je ne vois pas le rapport avec mes exemples : où vois-tu une manipulation de la pile dans mes exemples ?Envoyé par Patriarch24
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.Envoyé par Patriarch24
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.
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.Envoyé par Patriarch24
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é ?
Partager