Si tu utilise ton #define, tu à bien d'autres problèmes. Déjà tu est en train de mentir à l'utilisateur de ta macro, parce qu'il peut croire que c'est une fonction avec vérification des paramètres et documentation.
Ensuite si ta macro à un problème, ou si l'utilisateur à une autre variable qui s'appelle "func", t'aura avec la plupart des compilos des messages d'erreurs incompréhensibles du genre "func indéfini" ou "func ne peut pas être indéxé" alors qu'il n'y a pas "func" dans la ligne en question.
Si ça te fait plaisir de mettre tout ton code dans des macros et d'avoir que main() comme fonction, c'est ton problème.
De plus, Le inlining n'est pas du tout une garantie (cfr. le standard). Il peut encore dans de nombreux cas avoir un appel. Un appel coûte dans 99.9% des cas extrêmement plus qu'un accès mémoire.
Le standard ne te garanti pas qu'inliner sera forcement plus rapide que d'appeler une fonction, et ne te garanti pas non plus que ton compilo ne dé-inline pas ton code si tu fait trop de copier/coller.
Mais si tu ne fait tellement pas confiance à ton compilateur, change le. Quand gcc refuse d'inliner, il peut te dire pourquoi, et tu peut bidouiller les heuristiques de gcc si tu te crois plus malin que lui. Mais n'oublie pas que la plupart des problèmes d'optimisations sont NP-complet, et que gcc peut refuser d'optimiser une fonction si elle devient trop compliquée pour éviter que le temps de compilation explose.
[^] # Re: Tu utilises un tableau
Posté par Batchyx . En réponse au message Coût d'un accès mémoire.. Évalué à 2.
Si tu utilise ton #define, tu à bien d'autres problèmes. Déjà tu est en train de mentir à l'utilisateur de ta macro, parce qu'il peut croire que c'est une fonction avec vérification des paramètres et documentation.
Ensuite si ta macro à un problème, ou si l'utilisateur à une autre variable qui s'appelle "func", t'aura avec la plupart des compilos des messages d'erreurs incompréhensibles du genre "func indéfini" ou "func ne peut pas être indéxé" alors qu'il n'y a pas "func" dans la ligne en question.
Si ça te fait plaisir de mettre tout ton code dans des macros et d'avoir que main() comme fonction, c'est ton problème.
Le standard ne te garanti pas qu'inliner sera forcement plus rapide que d'appeler une fonction, et ne te garanti pas non plus que ton compilo ne dé-inline pas ton code si tu fait trop de copier/coller.
Mais si tu ne fait tellement pas confiance à ton compilateur, change le. Quand gcc refuse d'inliner, il peut te dire pourquoi, et tu peut bidouiller les heuristiques de gcc si tu te crois plus malin que lui. Mais n'oublie pas que la plupart des problèmes d'optimisations sont NP-complet, et que gcc peut refuser d'optimiser une fonction si elle devient trop compliquée pour éviter que le temps de compilation explose.