J'essaierai de répondre à votre question, bien que ce soit une vieille question, et elle n'a pas l'air très importante (ce n'est vraiment pas très important en soi ), et elle a déjà reçu d'assez bonnes réponses. La raison pour laquelle je veux y répondre est que cela se rapporte à des problèmes fondamentaux de l'évolution standard et de la conception du langage lorsque le langage est basé sur un langage existant: quand les fonctionnalités du langage doivent-elles être obsolètes, supprimées ou modifiées de manière incompatible?
En C ++, il est possible d'utiliser le mot-clé static dans une unité de traduction pour affecter la visibilité d'un symbole (déclaration de variable ou de fonction).
Le lien en fait.
Dans n3092, ceci était obsolète:
La dépréciation indique:
- L' intention de supprimer certaines fonctionnalités à l'avenir; cela ne signifie pas que les fonctionnalités obsolètes seront supprimées dans la prochaine révision standard, ou qu'elles devront être supprimées "bientôt", ou pas du tout. Et les fonctionnalités non obsolètes peuvent être supprimées dans la prochaine révision standard.
- Une tentative formelle de décourager son utilisation .
Ce dernier point est important. Bien qu'il n'y ait jamais de promesse formelle que votre programme ne sera pas rompu, parfois silencieusement, par la prochaine norme, le comité devrait essayer d'éviter de briser un code «raisonnable». La dépréciation devrait indiquer aux programmeurs qu'il est déraisonnable de dépendre de certaines fonctionnalités .
Cela souligne cependant que pour la compatibilité avec C (et la possibilité de compiler des programmes C en C ++), la dépréciation est ennuyeuse. Cependant, compiler un programme C directement en C ++ peut déjà être une expérience frustrante, donc je ne sais pas si cela mérite d'être pris en considération.
Il est très important de conserver un sous-ensemble commun C / C ++, en particulier pour les fichiers d'en-tête. Bien entendu, staticles déclarations globales sont des déclarations de symbole avec lien interne et cela n'est pas très utile dans un fichier d'en-tête.
Mais le problème n'est pas seulement la compatibilité avec C, c'est la compatibilité avec le C ++ existant: il existe des tonnes de programmes C ++ valides existants qui utilisent staticdes déclarations globales. Ce code n'est pas seulement formellement légal, il est sain, car il utilise une fonctionnalité de langage bien définie de la manière dont il est destiné à être utilisé .
Ce n'est pas parce qu'il existe maintenant une «meilleure façon» (selon certains) de faire quelque chose que les programmes écrits à l'ancienne sont «mauvais» ou «déraisonnables». La possibilité d'utiliser le staticmot - clé sur les déclarations d'objets et de fonctions à portée globale est bien comprise dans les communautés C et C ++, et le plus souvent utilisée correctement.
Dans la même veine, je ne vais pas changer les moulages de style C doubleen static_cast<double>simplement parce que "les moulages de style C sont mauvais", car cela static_cast<double>n'ajoute aucune information et aucune sécurité.
L'idée que chaque fois qu'une nouvelle façon de faire quelque chose est inventée, tous les programmeurs se précipiteraient pour réécrire leur code de travail bien défini existant est tout simplement folle. Si vous voulez supprimer toute la laideur et les problèmes hérités du C, vous ne changez pas le C ++, vous inventez un nouveau langage de programmation. La suppression de la moitié d'une utilisation de staticrend à peine C ++ moins C-laid.
Les changements de code nécessitent une justification, et «vieux est mauvais» ne justifie jamais les changements de code.
Les changements de langue brisés nécessitent une justification très forte. Rendre le langage très légèrement plus simple ne justifie jamais un changement radical.
Les raisons données pour lesquelles staticest mauvais sont simplement remarquablement faibles, et il n'est même pas clair pourquoi les objets et les déclarations de fonctions ne sont pas déconseillés ensemble - leur donner un traitement différent ne rend guère le C ++ plus simple ou plus orthogonal.
Alors, vraiment, c'est une triste histoire. Pas à cause des conséquences pratiques qu'il a eues: il n'a eu exactement aucune conséquence pratique. Mais parce que cela montre clairement un manque de bon sens de la part du comité ISO.