Langage C#
  1. Langage C#
  3. Pourquoi n’y a-t-il pas de méthode membre const dans les parameters C # et const?
Intereting Posts
Comment définir une chaîne de connexion à une firebase database SQL Server 2008? Les migrations d’Entity Framework 6 peuvent-elles inclure une transaction autour de scripts? Aide à corriger les erreurs en C # “Un argument ref ou out doit être assignable” exemples de test du domaine avec joliver commondomain / eventstore Le programme C # se bloque lors de l’écriture avec StreamWriter NetworkStream.Write vs. Socket.Send Obtenir la valeur de la zone de texte ajoutée dynamicment à partir du tableau situé dans le panneau de mise à jour Comment implémenter la logique de nouvelle tentative avec TPL (tâche parallèle) Pourquoi Datareader ne peut pas être initialisé? Déplacement de 2 formulaires en même temps Pouvez-vous lier la visibilité d’une GroupBox à la visibilité de ses enfants? Comment lier une ComboBox afin que le membre d’affichage puisse concaténer 2 champs de données datables? jour par mois Ajout de plusieurs valeurs à la variable Enum Type jouer deux sons simultanément dans Windows 8 Metro App (C # / XAML)

Pourquoi n’y a-t-il pas de méthode membre const dans les parameters C # et const?

Contrairement à C ++, il n’y a pas de méthode membre const ni de parameters const en C #. Quelle est la raison?

Tout d’abord, il n’est pas nécessaire que nous fournissions une raison pour ne pas implémenter une fonctionnalité. Les fonctionnalités sont extrêmement chères; il doit exister une justification pour l’ implémentation d’une fonctionnalité, pas une justification pour ne pas l’ implémenter.

Deuxièmement, C # n’est pas un clone de C ++ ou C. Le simple fait qu’une fonctionnalité soit dans un autre langage n’est pas une raison pour la mettre en C #.

Troisièmement, “const” est profondément, tragiquement cassé en C et C ++. “const” ne vous donne aucune garantie sur laquelle vous pouvez compter. Si vous êtes l’appelant d’une méthode qui prend une référence const, vous n’avez aucune garantie que la méthode respecte la constness; la méthode a plusieurs façons de muter une référence const. Si vous êtes le consommateur d’une référence const, vous n’avez aucune garantie que l’object sous-jacent ne mutera pas de manière arbitraire. Étant donné que le contrat n’est appliqué ni du côté appelant ni du côté appelé, il est beaucoup plus faible que toute autre garantie que nous aimerions offrir dans le système de typage. Nous ne voudrions pas reproduire un système aussi défaillant.

Quasortingèmement, mettre constness dans le système de types CLR signifie que chaque langage devrait utiliser la même implémentation de constness; étant donné que différentes langues ont différentes significations pour constness, il serait plus difficile d’apporter plus de langues dans le CLR, pas plus facile .

Il existe de nombreuses raisons de ne pas utiliser cette fonctionnalité extrêmement coûteuse et très peu de raisons de le faire. Les fonctionnalités coûteuses et injustifiées ne sont pas implémentées.

C # ne l’a pas parce que .NET n’en a pas. Ce n’est pas le cas de .NET parce que l’équipe de développement CLR a décidé que cela ne valait pas la peine.

Vous pouvez lire sur des blogs consacrés à la SEP tels que “The Old New Thing” de Raymond Chen ou “Fabulous Adventures in Coding” d’Eric Lippert, sur la définition des priorités par Microsoft .

Il y a un article décent ici par Stan Lippman.