En C ++, il est possible d'utiliser le staticmot - clé dans une unité de traduction pour affecter la visibilité d'un symbole (déclaration de variable ou de fonction).
Dans n3092, ceci était obsolète:
Annexe D.2 [depr.static]
L'utilisation du mot clé static est déconseillée lors de la déclaration d'objets dans la portée de l'espace de noms (voir 3.3.6).
Dans n3225, cela a été supprimé.
Le seul article que j'ai pu trouver est un peu informel.
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.
Est-ce que quelqu'un sait pourquoi il a été changé?
Réponses:
Dans C ++ Standard Core Language Defect Reports and Accepted Issues, Revision 94 under 1012. Undeprecating static `ils notent:
En gros, dire que la dépréciation de
staticn'a pas vraiment de sens. Il ne sera jamais supprimé de C ++, et il est toujours utile car vous n'avez pas besoin du code standard dont vous avez besoin avec des espaces de noms sans nom, si vous souhaitez simplement déclarer une fonction ou un objet avec un lien interne.la source
static class ..., OTOH, ne fonctionnera pas.namespace {" et "}"?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?
Le lien en fait.
La dépréciation indique:
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 .
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
doubleenstatic_cast<double>simplement parce que "les moulages de style C sont mauvais", car celastatic_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.
la source
staticou des espaces de noms anonymes, je n'encourage ni ne décourage non plus. Ce que je veux dire, c'est que si vous voulez vraiment décourager les gens d'utiliser des espaces de noms anonymes, vous devez leur donner de bons arguments. En pratique, je crois que dans la plupart des implémentations, les entités déclarées dans un espace de noms sans nom sont des symboles exportés avec un nom aléatoire, augmentant ainsi la table d'exportation. Les entités déclarées commestaticOTOH ne sont en aucun cas exportées. Ainsi, de nombreuses personnes choisissent, sur la base de cette observation, d'utiliserstatic.staticne disparaîtra jamais, il est donc erroné de la désapprouver. " Pourtant, vous ne faites aucun argument selon lequel décourager son utilisation est une erreur. " Je n'ai vu aucun argument convaincant qui montre que l'utilisation de la portée de l'espace de nomsstaticest "incorrecte". Le déprécier juste pour décourager son utilisation est une erreur, parce que personne ne croit réellement qu'il va disparaître, et parce que cela ne convainc pas les gens que son utilisation est "mauvaise".Déconseillée ou non, la suppression de cette fonctionnalité de langue briserait les codes existants et ennuyait les gens.
Tout le problème de la dépréciation statique était juste un vœu pieux comme "les espaces de noms anonymes sont meilleurs que statiques" et "les références sont de meilleurs pointeurs". Lol.
la source
char* foo = new char; char& ref = *foo;fait qu'un pointeur vous soit initialement donné ne dit absolument rien sur votre capacité à utiliser des références.