void Animation::playAnimation() const
{
static const int index = 0;
const std::string& animationFileName =
m_animationContainer.getAnimationName(index);
static const int zOrder = -1;
static bool isLooping = false;
AnimationBank::play(animationFileName,
zOrder,
isLooping);
}
Y a-t-il un avantage à définir des variables locales constantes comme static
? Ou c'est une pratique inutile et même mauvaise.
Au-delà de la très bonne réponse de @ Christophe, le code généré pour la statique est probablement pire que celui de la variable locale, donc si vous êtes intéressé par l'avantage sous le capot, la statique est pire sur les processeurs modernes.
La raison en est que la statique doit être située quelque part dans la mémoire qui peut être trouvée par tous les autres threads et par toutes les autres invocations. Cela signifie essentiellement les mettre dans la mémoire globale.
Au fil des ans, les processeurs et les compilateurs ont ensemble considérablement optimisé l'accès aux variables locales en raison de la popularité de leur utilisation, par rapport à d'autres variables, telles que les variables globales, statiques et les champs. Le compilateur peut choisir de stocker une variable locale dans un registre CPU, et même si ce n'est pas le cas (il utilise donc la pile d'invocation à la place), toute la pile est presque certainement dans le cache. L'accès à la pile est généralement un mode d'adressage à déplacement court (hors du registre de pointeur de pile). Cependant, l'accès aux globaux ou aux statiques nécessite généralement un décalage étendu ou une adresse absolue, de sorte que les instructions qui en résultent sont plus longues que leur équivalent pour l'accès à la mémoire de la pile.
Tout cela étant dit, en raison de la combinaison de statique et de const, le compilateur peut détecter qu'il peut remplacer la valeur constante au point d'utilisation, donc peut-être que l'utilisation de const atténue ce qui précède. Pourtant, votre extrait de code montre au moins une statique non constante, donc la discussion est peut-être d'actualité.
Ce n'est pas une question d'avantages, mais une question de sémantique:
Une variable statique dans une fonction (même une fonction membre) signifie que la variable est partagée entre tous les appels de cette fonction. Un appel de cette fonction a donc un effet secondaire sur les appels suivants.
Une variable non statique est unique à chaque exécution de la fonction.
Donc, à moins que cela ne soit nécessaire pour une raison spécifique et bien justifiée, gardez les variables locales non statiques.
Remarque supplémentaire: La variable statique est également partagée entre différents threads. Donc, appeler cette fonction à partir de plusieurs threads à la fois peut entraîner des conditions de concurrence critique et UB (même si elle est appelée pour différents objets).
Une variable locale est initialisée ou construite à chaque appel de la fonction. Les variables locales sont stockées sur la pile et sont donc généralement thread-safe.
Une variable locale statique n'est initialisée ou construite qu'une seule fois; la première fois que la fonction est appelée. Les variables statiques locales ne sont pas stockées sur la pile et ne sont donc généralement pas sécurisées pour les threads.
Une variable locale const est une variable qui ne change pas et est initialisée ou construite à chaque appel de la fonction. Les variables const locales sont stockées sur la pile et sont donc généralement thread-safe.
Une variable locale const statique est une variable qui ne change pas et qui est initialisée ou construite une seule fois; la première fois que la fonction est appelée. Les variables const locales statiques ne sont pas stockées sur la pile et ne sont donc généralement pas thread-safe.
Les compilateurs peuvent être en mesure d'optimiser les variables const en une constante de temps de compilation.
Les compilateurs peuvent être en mesure d'optimiser les variables non statiques en les conservant dans des registres plutôt que sur la pile.