J'apprends à programmer et, parfois, je trouve que l'utilisation d'une variable à revenir rend mon code plus lisible.
Je me demandais si ces fonctions effectuent les mêmes opérations et sont tout aussi efficaces.
cas 1: Dans ce cas, je pense que l'initialisation et la somme se produisent au moment de la compilation, donc il n'y a pas de différence entre eux. cas 2: mais ce qui se passe dans ce cas? Il semble que l'initialisation se produise au moment de l'exécution et qu'il doit l'exécuter. renvoie la valeur directement plus rapidement que d'initialiser une variable puis de le renvoyer? Devrais-je toujours essayer de retourner directement des valeurs à la place à l'aide d'une variable pour revenir?
3 Réponses :
Case 2 est plus efficace, mais n'est souvent pas nécessaire car le compilateur est extrêmement susceptible d'optimiser le boîtier 1 dans le cas 2.
aller pour la lisibilité si cela ne fait pas mal de performance (comme dans ce cas).
Vous pouvez facilement essayer cela vous-même.
Vous pouvez obtenir l'assemblage de votre compilateur
sans optimisation:
( GCC -S -O0 -O SRC.S SRC.C CODE>) P> .file "so_temp.c"
.text
.p2align 4,,15
.globl case1Foo1
.type case1Foo1, @function
case1Foo1:
.LFB0:
.cfi_startproc
movl $18, %eax
ret
.cfi_endproc
.LFE0:
.size case1Foo1, .-case1Foo1
.p2align 4,,15
.globl case1Foo2
.type case1Foo2, @function
case1Foo2:
.LFB5:
.cfi_startproc
movl $18, %eax
ret
.cfi_endproc
.LFE5:
.size case1Foo2, .-case1Foo2
.p2align 4,,15
.globl case2Foo1
.type case2Foo1, @function
case2Foo1:
.LFB2:
.cfi_startproc
leal 13(%rdi), %eax
ret
.cfi_endproc
.LFE2:
.size case2Foo1, .-case2Foo1
.p2align 4,,15
.globl case2Foo2
.type case2Foo2, @function
case2Foo2:
.LFB7:
.cfi_startproc
leal 13(%rdi), %eax
ret
.cfi_endproc
.LFE7:
.size case2Foo2, .-case2Foo2
.ident "GCC: (Ubuntu 8.3.0-6ubuntu1) 8.3.0"
.section .note.GNU-stack,"",@progbits
Tout compilateur de qualité au moins modeste sera, voire de faibles niveaux d'optimisation (tels que GCC La norme C ne nécessite pas de compilateurs de compiler de manière irréfléchie dans des instructions qui effectuent les étapes exactes dans le code source C. Cela nécessite uniquement des compilateurs de produire du code qui a les mêmes effets. Ces effets sont définis en termes de comportement observable , qui inclut la sortie du programme, les interactions avec l'utilisateur et l'accès à des objets volatils (objets spéciaux que vous en apprendrez plus tard). Les compilateurs élimineront les choses comme des variables intermédiaires tant qu'ils peuvent le faire sans changer le comportement observable. -O1 ), compilez-les au même code . Pour la plupart, toute optimisation correcte que vous puissiez voir facilement sera effectuée par un bon compilateur.
Le compilateur les compilera dans de nombreux cas dans le même code. S'inquiéter de la lisibilité au lieu de la performance dans un cas comme celui-ci.
"Renvoie la valeur directement plus vite ...." -> C'est une optimisation prématurée. Concentrez-vous sur des problèmes plus importants et laissez le compilateur gérer les petites choses.
@chux: Ils n'étaient pas optimisent un programme, ce n'est donc pas prématuré. Ils posent des questions sur les principes, d'informer leur pensée et d'être utilisés plus tard, pour ne pas optimiser un programme en cours.
Un avantage de l'opération divisée est que vous pouvez mettre un point d'arrêt de débogage sur la déclaration de retour et imprimer la valeur qui sera renvoyée. Si l'expression fait partie du retour, vous ne pouvez pas le faire, de trouver la valeur de retour réelle est plus difficile. Cela suppose que vous ne faites pas trop d'optimisation tout en débogage. Lorsque vous optimisez, il n'y aura pas beaucoup si une différence - le compilateur réécrire efficacement à un retour direct, il n'y a donc aucune pénalité.
Le meilleur commentaire va à Jonathan Leffler. Une énorme chose est que vous puissiez mettre un point d'arrêt de débogueur sur le retour. Surtout dans les cas où vous avez de nombreuses fonctions dans la pile d'appels ayant la même chose à retourner quelque chose; renvoyer quelque chose; Jusqu'à ce que peut-être 5-7 fonctionne jusqu'à ce que vous puissiez voir la valeur ... plus clairement.