EG
int a_long_variable_name_used_instead_of_small_one=3;//-------------(2)
10 Réponses :
Dans les compilateurs modernes Le nom d'une variable n'a pas d'impact sur la quantité d'espace nécessaire pour la maintenir en C ++. P>
Même dans les plus anciens compilateurs, Afaik. C ++ n'a jamais eu de fonctionnalité introspection. :)
Les deux occupent la même quantité de mémoire. Les noms de variables ne sont que pour vous aider, le programmeur, rappelez-vous quelle est la variable pour et d'aider le compilateur associé à différentes utilisations de la même variable. À l'exception des symboles de débogage, ils ne font aucune apparence dans le code compilé. P>
Puisqu'il a étiqueté la question comme langue-agnostique (entre autres), que diriez-vous des langues prenant en charge la réflexion au moment de l'exécution?
Ou des langues qui utilisent une carte simple à partir du nom de variable à la valeur aux variables de recherche (je suis sûr qu'il y a des langues interprétées qui le font)
@ SEPP2K: Par exemple, les variables globales de Lua sont levées en utilisant une carte de hachage.
Notez que, à la place, les noms de classe / struct peuvent compter si vous activez RTTI, car leurs noms dans ce cas doivent être stockés dans l'exécutable. EDIT: Juste pour préciser, je parle de C ++.
@Space, @ SEPP2K: À l'origine, il venait de taguer comme C ++.
Le nom que vous donnez à une variable en C / C ++ n'affectera pas la taille du code exécutable résultant. Lorsque vous déclarez une variable comme celle-ci, le compilateur réserve em> espace mémoire (dans le cas d'une INT sur x86 / x64, quatre octets) pour stocker la valeur. Pour accéder ou modifier la valeur, il utilisera ensuite l'adresse plutôt que le nom de la variable (qui est perdu dans le processus de compilation). P>
non .. les deux occuperont l'espace égal .. p>
Si ma compréhension est correcte, ils prendront la même quantité de mémoire. Je crois (et je suis prêt à être abattu en flammes) que, en C ++, les noms sont symboliques pour aider l'utilisateur et le compilateur à créer un bloc de mémoire suffisant pour contenir le type que vous déclarez, dans ce cas une INT. Donc, ils devraient tous les deux occuper la même taille de la mémoire, c'est-à-dire la mémoire requise pour contenir une adresse. P>
Dans la plupart des langages interprétés, le nom serait stocké dans une table quelque part en mémoire, prenant ainsi différentes quantités d'espace. P>
en C ++ et les langages compilés statiquement statiquement, les noms de variables peuvent prendre plus d'espace pendant le processus de compilation, mais par le temps d'exécution, les noms auront été supprimés et ne prennent donc pas de place du tout. P>
dans les langages interprétés et les langages compilés qui fournissent l'introspection / réflexion du temps d'exécution, le nom peut prendre plus d'espace. P>
En outre, la mise en œuvre de la langue affectera la hausse des noms de variable spatiaux. L'exécutant a peut-être décidé d'utiliser un tampon de longueur fixe pour chaque nom de variable, auquel cas chaque nom prend le même espace quelle que soit la longueur. Ou ils peuvent avoir une place allouée de manière dynamique basée sur la longueur. P>
Pour C ++, cela dépend si vous compilez avec des symboles ou non. Pour déboguer les décharges de noyau, j'apprécie que mes symboles soient expédiés dans le binaire / la bibliothèque, dans ce cas, mais les noms longs peuvent affecter la taille (même si un seul nom ne serait pas vraiment ...)
Oui, cela rend la taille du fichier plus grosse, il ne faut pas prendre plus de mémoire que si vous l'exécutez sous un débogueur
Noms de champ (noms de variable d'instance) dans la mémoire d'utilisation Java, mais une fois par champ. Ceci est pour la réflexion au travail. Il en va de même pour d'autres langues basées sur la JVM, et je suppose pour DotNet. P>
pour C ++,
$ cat name.cpp int main() { int a = 74678; int bcdefghijklmnopqrstuvwxyz = 5664; } $ g++ -S name.cpp $ cat name.s .file "name.cpp" .text .align 2 .globl main .type main, @function main: .LFB2: pushl %ebp .LCFI0: movl %esp, %ebp .LCFI1: subl $8, %esp .LCFI2: andl $-16, %esp movl $0, %eax addl $15, %eax addl $15, %eax shrl $4, %eax sall $4, %eax subl %eax, %esp movl $74678, -4(%ebp) movl $5664, -8(%ebp) movl $0, %eax leave ret .LFE2: .size main, .-main .section .note.GNU-stack,"",@progbits .ident "GCC: (GNU) 3.4.6 20060404 (Red Hat 3.4.6-11.0.1)" $
compilateurs sont là pour une raison ... Ils optimisent le code pour utiliser un peu d'espace que possible et fonctionnent aussi vite que possible les plus modernes. P>
Les noms aussi longs que dans (2) prendront plus de mémoire dans la tête du programmeur :)
Le titre dit "dans n'importe quel langage de programmation", mais les tags disent "C ++" (avant que Martin ait ajouté la balise "Langue-Agnostic"). C'est lequel alors?
Tout ce que vous envisagez d'avoir un entier dont je parle, mais je dis que tout lieu dans la mémoire A et a_long_variable_name_Instead_of_small_one prenez un peu de place ou non
Même dans les langues où il comptait, si vous suggérez même à distance en utilisant des noms moins descriptifs pour "sauvegarder la mémoire", ne le faites pas! Écrivez d'abord le code Effacer!