9
votes

Variables locales statiques dans les méthodes une mauvaise pratique?

Il y a quelque chose qui me dérange.

Dans un programme non fileté, il est-il préférable d'avoir des variables statiques locales (méthodes intérieures) ou des membres de la classe statique? p>

dans cet exemple: P>

class C{
public: 
  C(){};
  void foo();
};

void C::foo(){
  static int bar = 0;
  bar++;
  printf("%d\n",bar);
}


0 commentaires

6 Réponses :


0
votes

La barre orientée objet, la barre fait partie de l'état de la classe C. C'est la raison pour laquelle je préfère généralement utiliser des champs plutôt que des variables locales statiques.


3 commentaires

état de quel objet? Les variables globales (statistiques dans cet exemple) ne font pas partie de l'état d'un objet, elles font partie de l'État global.


Non ce n'est pas le cas. Seuls les membres non statiques peuvent servir d'objet d'un objet.


-1 Vous ne savez pas que bar fait partie de l'état de la classe ". Il peut faire partie de l'état de la fonction membre . Dans ce cas, une statique locale est appropriée.



7
votes

Ni est meilleur. Ils servent des cas d'utilisation très différents


2 commentaires

Le début de votre réponse semble prometteur, mais pourriez-vous élaborer?


@Iiyan, la sémantique de son code est "imprimée combien de fois" foo 'a été appelée! ". D'après ce que l'on peut voir dans sa question, cela n'a rien à voir avec l'état de la classe, et il serait donc faux de mettre la variable en tant que membre de la classe statique. Si toutefois FOO serait un constructeur de copie et Barre serait appelé Numberfcopies , ce serait un bon candidat à un membre de la classe statique. Cela dépend donc de la façon dont il est utilisé.



2
votes

Si c'est une classe publique, un membre de la classe statique nécessite de modifier le fichier d'en-tête. Ce n'est pas toujours souhaitable.

Une autre option est une variable scopée de fichiers, dans un espace de noms anonyme. Ceci suffit si vous avez besoin d'un accès uniquement dans une méthode, et si vous en avez besoin dans plusieurs.


0 commentaires

0
votes

Les variables mondiales locales et non locales sont "mauvaises" par la vertu d'être globales. Mais l'initialisation et l'accès pour ces deux cas sont différents, la réponse à laquelle l'utiliser dépend de vos besoins concernant ces besoins.

En tant que note latérale, l'initialisation dynamique des variables locales avec durée de stockage statique peut ne pas être du thread-coffre-fort, en fonction de votre compilateur. La bonne nouvelle, en C ++ 0x, il est garanti d'être le fil-faire.


4 commentaires

Il n'y a rien de mal avec les variables mondiales. Le problème est avec l'état mutable accessible à l'échelle mondiale. Ni est vrai ici.


@ Martinyork, cet état est global, mutable et accessible. Toute instance de c peut le changer.


@evoskuil Je commençais sur cette réponse. La déclaration: Les variables globales locales et non locales sont "mauvaises" . À sa propre déclaration, cette déclaration est fausse. La question (comme avec la question) est l'état mutable mondial.


@Eevoskuil: Cette question et cette réponse ont une vieille décennie. Pourquoi lisez-vous zéro point des réponses aux questions?



4
votes

J'essaie habituellement de limiter autant que possible la portée des variables, tant qu'elle ne devient ni étrange ni fastidieuse.

Si vous avez 1000 lignes de code dans Classe C , d'entre eux 100 lignes de code dans la fonction FOO , tout changement que vous faites sur BAR (par exemple, la modification du nom ou du type) nécessite de dépasser 100 lignes de code pour vous assurer que le changement est correct. Si vous aviez bar un membre de la classe statique, vous devrez peut-être accéder plus de 1000 lignes de code, juste pour vous assurer que bar n'est pas utilisé là-bas. Ce serait une perte de temps.

Si vous pensez que vous devriez avoir besoin de bar dans une autre fonction FOO2 (par exemple, lors de compter le nombre d'appels pour FOO FOO2 ensemble), vous voudrez peut-être effectuer une barre un membre de la classe statique.


1 commentaires

+1 Minimiser la portée variable «statique» est importante. Module global vs.CPP par rapport à la classe par rapport à la méthode / fonction vs. Bloc de {}. J'ai tendance à préférer utiliser les données statiques du niveau de module .CPP sur une déclaration de classe, car si vous le collez dans l'en-tête de la classe, les clients dépendent maintenant des détails de la mise en œuvre.



0
votes

Je considérerais l'utilisation de statiques des membres const (qui ne sont pas éligibles pour consexpr ) s'entraîner. La portée d'un membre statique ou d'une méthode locale est globale , elle ne peut être accessible que par (toutes les instances de) une classe.

Classe de non-Const Statique est en haut de ma liste pour les mauvaises pratiques. C'est pire que de simplement déclarer une variable globale - car il est caché. Une classe singleton (ou même une classe que vous ne construisez qu'une seule fois et que vous passerez à des cours dépendantes) élimine cette pratique.

Mais sinon je recommanderais d'exposition de la statique via un accesseur mondial (avec de grands commentaires laids autour de lui ). Si, à tout moment, le code devient simultané, vous pouvez déposer dans une section critique. xxx


0 commentaires