Dépréciation du mot-clé static... plus rien ?

Question

En C++, il est possible d'utiliser la fonction static dans une unité de traduction pour affecter la visibilité d'un symbole (déclaration de variable ou de fonction).

Dans la n3092, ceci a été déprécié :

Annexe D.2 [depr.static]
L'utilisation du mot clé static est dépréciée lors de la déclaration d'objets dans la portée d'un espace de nom (voir 3.3.6).

Dans la n3225, cela a été supprimé.

El le seul article que j'ai pu trouver est quelque peu informel.

Cela souligne cependant que, pour la compatibilité avec le C (et la possibilité de compiler des programmes C en C++), la dépréciation est gênante. Cependant, compiler un programme C directement en C++ peut déjà être une expérience frustrante, donc je ne suis pas sûr que cela mérite d'être pris en considération.

Quelqu'un sait-il pourquoi il a été modifié ?

Answer 1

Sur Rapports de défauts et problèmes acceptés du langage de base standard C++, révision 94 sous 1012. Undeprecating static ils notent :

Bien que 7.3.1.1 [namespace.unnamed] stipule que l'utilisation du mot-clé static pour déclarer des variables dans la portée de l'espace de noms est dépréciée parce que l'espace de noms sans nom fournit une alternative supérieure, il est peu probable que cette fonctionnalité soit supprimée dans un avenir prévisible.

En gros, cela revient à dire que la dépréciation de l'option static n'a pas vraiment de sens. Il ne sera jamais supprimé du C++. Il est toujours utile parce que vous n'avez pas besoin du code passe-partout dont vous auriez besoin avec des objets sans nom. namespace si vous souhaitez simplement déclarer une fonction ou un objet avec un lien interne.

Answer 2

Je vais essayer de répondre à votre question, bien qu'elle soit ancienne et qu'elle ne semble pas très importante (elle ne l'est vraiment pas). en soi ), et elle a déjà reçu d'assez bonnes réponses. La raison pour laquelle je veux y répondre est qu'elle concerne les questions fondamentales de l'évolution des normes et de la conception des langages lorsque le langage est basé sur un langage existant : quand les caractéristiques du langage doivent-elles être dépréciées, 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).

L'attelage en fait.

Dans la n3092, ceci a été déprécié :

La dépréciation est indiquée :

• El intention pour supprimer une fonctionnalité dans le futur ; cela ne signifie pas que les fonctionnalités dépréciées seront supprimées lors de la prochaine révision de la norme, ni qu'elles doivent être supprimées "bientôt", voire pas du tout. Les fonctionnalités non dépréciées peuvent être supprimées lors de la prochaine révision de la norme.
• 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 cassé, parfois silencieusement, par la prochaine norme, le comité devrait essayer d'éviter de casser du code "raisonnable". La dépréciation devrait indiquer aux programmeurs que il n'est pas raisonnable de dépendre d'une certaine caractéristique .

Cela souligne cependant que, pour la compatibilité avec le C (et la possibilité de compiler des programmes C en C++), la dépréciation est gênante. Cependant, compiler un programme C directement en C++ peut déjà être une expérience frustrante, donc je ne suis pas sûr que cela mérite d'être pris en considération.

Il est très important de préserver un sous-ensemble commun C/C++, notamment pour les fichiers d'en-tête. Bien sûr, static Les déclarations globales sont des déclarations de symboles avec des liens internes, ce qui n'est pas très utile dans un fichier d'en-tête.

Mais le problème n'est jamais seulement la compatibilité avec le C, c'est la compatibilité avec le C++ existant : il y a des tonnes de programmes C++ valides existants qui utilisent static déclarations globales. Ce code n'est pas seulement formellement légal, il est sain, car il utilise une caractéristique du langage bien définie de la manière dont il est censé être utilisé .

Ce n'est pas parce qu'il existe aujourd'hui une "meilleure façon" (selon certains) de faire quelque chose que les programmes écrits selon l'ancienne méthode sont "mauvais" ou "déraisonnables". La possibilité d'utiliser le static sur les déclarations d'objets et de fonctions à portée globale est bien compris dans les communautés C et C++, et le plus souvent utilisé correctement.

Dans le même ordre d'idées, je ne vais pas changer les castings du style C en double a static_cast<double> juste parce que "les casts de style C sont mauvais", comme static_cast<double> ajoute zéro information et zéro 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écipitent pour réécrire leur code existant bien défini est tout simplement folle. Si vous voulez supprimer tous les problèmes et laideurs hérités du C, vous ne modifiez pas le C++, vous inventez un nouveau langage de programmation. Suppression d'une moitié de l'utilisation de static ne rend pas le C++ moins moche.

Les changements de code doivent être justifiés, et "l'ancien est mauvais" n'est jamais une justification pour les changements de code.

Les modifications du langage de rupture nécessitent une justification très solide. Simplifier très légèrement le langage n'est jamais une justification pour un changement de rupture.

Les raisons invoquées pour lesquelles static est mauvais sont juste remarquablement faibles, et il n'est même pas clair pourquoi les objets et les déclarations de fonctions ne sont pas dépréciés ensemble - leur donner un traitement différent ne rend pas le C++ plus simple ou plus orthogonal.

Donc, vraiment, c'est une histoire triste. Non pas à cause des conséquences pratiques qu'elle a eues : elle n'a eu exactement aucune conséquence pratique. Mais parce qu'elle montre un manque évident de bon sens de la part du comité ISO.

Answer 3

Dépréciée ou non, la suppression de cette fonctionnalité du langage briserait les codes existants et gênerait les gens.

Toute cette histoire de dépréciation de la statique n'était qu'un vœu pieux du genre "les espaces de noms anonymes sont meilleurs que la statique" et "les références sont de meilleurs pointeurs". Lol.