c# caractère spéciaux - Quelle est la différence entre String et string en C #?




15 Answers

Juste pour être complet, voici un tas d’informations connexes ...

Comme d'autres l'ont noté, string est un alias de System.String . Ils compilent dans le même code, donc au moment de l'exécution, il n'y a aucune différence. Ceci est juste un des alias en C #. La liste complète est:

object:  System.Object
string:  System.String
bool:    System.Boolean
byte:    System.Byte
sbyte:   System.SByte
short:   System.Int16
ushort:  System.UInt16
int:     System.Int32
uint:    System.UInt32
long:    System.Int64
ulong:   System.UInt64
float:   System.Single
double:  System.Double
decimal: System.Decimal
char:    System.Char

En dehors de string et object , les alias sont tous des types valeur. decimal est un type de valeur, mais pas un type primitif dans le CLR. Le seul type primitif qui n'a pas d'alias est System.IntPtr .

Dans la spécification, les alias de type valeur sont appelés "types simples". Les littéraux peuvent être utilisés pour les valeurs constantes de chaque type simple; aucun autre type de valeur n'a de forme littérale disponible. (Comparez cela avec VB, qui autorise les littéraux DateTime et possède également un alias.)

Il existe une situation dans laquelle vous devez utiliser les alias: lorsque vous spécifiez explicitement le type sous-jacent d'une énumération. Par exemple:

public enum Foo : UInt32 {} // Invalid
public enum Bar : uint   {} // Valid

C'est juste une question de la façon dont la spécification définit les déclarations enum - la partie après le côlon doit être la production de type intégral , qui est un signe de sbyte , byte , short , ushort , int , uint , long , ulong , char . .. par opposition à une production de type telle qu'utilisée par les déclarations de variables, par exemple. Cela n'indique aucune autre différence.

Enfin, quand il s'agit d'utiliser: personnellement, j'utilise les alias partout pour l'implémentation, mais le type CLR pour toutes les API. Peu importe ce que vous utilisez en termes de mise en œuvre, la cohérence au sein de votre équipe est une bonne chose, mais personne d'autre ne s'en soucie. D'un autre côté, il est réellement important que si vous faites référence à un type dans une API, vous le fassiez de manière neutre. Une méthode appelée ReadInt32 est sans ambiguïté, alors qu'une méthode appelée ReadInt nécessite une interprétation. L'appelant peut utiliser un langage qui définit un alias int pour Int16 , par exemple. Les concepteurs du framework .NET ont suivi ce modèle, de bons exemples étant dans les BitConverter , BinaryReader et Convert .

operator caractere echappement

Exemple ( notez le cas ):

string s = "Hello world!";
String s = "Hello world!";

Quelles sont les directives pour l'utilisation de chacun? Et quelles sont les différences ?




La meilleure réponse que j'ai jamais entendue à propos de l'utilisation des alias de type fournis en C # provient de Jeffrey Richter dans son livre CLR Via C # . Voici ses 3 raisons:

  • J'ai vu un certain nombre de développeurs confus ne sachant pas s'il fallait utiliser string ou String dans leur code. Parce qu'en C #, la chaîne (un mot-clé) correspond exactement à System.String (un type FCL), il n'y a pas de différence et les deux peuvent être utilisés.
  • En C #, long est mappé sur System.Int64 , mais dans un langage de programmation différent, long peut être mappé sur un Int16 ou Int32 . En fait, C ++ / CLI traite en fait long comme un Int32 . Quelqu'un qui lit le code source dans une langue peut facilement mal interpréter l'intention du code s'il est habitué à programmer dans un langage de programmation différent. En fait, la plupart des langues ne traitent même pas le mot-clé et ne compilent pas le code qui l'utilise.
  • Le FCL a de nombreuses méthodes qui ont des noms de types dans leurs noms de méthodes. Par exemple, le type BinaryReader propose des méthodes telles que ReadBoolean , ReadInt32 , ReadSingle , etc., et le type System.Convert propose des méthodes telles que ToBoolean , ToInt32 , ToSingle , etc. Bien qu'il soit légal d'écrire le code suivant, la ligne avec float ne me semble pas très naturelle, et il n'est pas évident que la ligne soit correcte:
BinaryReader br = new BinaryReader(...);
float val  = br.ReadSingle(); // OK, but feels unnatural
Single val = br.ReadSingle(); // OK and feels good

Donc là vous l'avez. Je pense que ce sont tous de très bons points. Cependant, je ne me trouve pas en train d'utiliser les conseils de Jeffrey dans mon propre code. Peut-être que je suis trop coincé dans mon monde C # mais je finis par essayer de faire ressembler mon code au code-cadre.




Il y a une différence : vous ne pouvez pas utiliser String sans using System; préalablement.




System.String est la classe de chaînes .NET. En C #, string est un alias pour System.String . Par conséquent, leur utilisation est identique.

En ce qui concerne les directives, je ne m'embourberais pas trop et utiliserais ce que vous voudriez être - il y a des choses plus importantes dans la vie et le code sera le même de toute façon.

Si vous vous trouvez en train de construire des systèmes où il est nécessaire de spécifier la taille des entiers que vous utilisez et que vous avez tendance à utiliser Int16 , Int32 , UInt16 , UInt32 etc., il peut sembler plus naturel d'utiliser String - et lorsque vous vous déplacez entre différents Les langages .net pourraient rendre les choses plus compréhensibles - sinon, j'utiliserais string et int.




string et String sont identiques à tous égards (sauf le "S" majuscule). Aucune conséquence sur les performances.

Les string minuscules sont préférées dans la plupart des projets en raison de la coloration syntaxique




Cette vidéo sur YouTube montre pratiquement en quoi elles diffèrent.

Mais maintenant, pour une longue réponse textuelle.

Lorsque nous parlons de .NET il y a deux choses différentes, l'une est le .NET et l'autre, des langages ( C# , VB.NET etc.) qui utilisent ce framework.

" System.String " aka "String" (la majuscule "S") est un type de données .NET Framework tandis que "string" est un type de données C# .

En bref "String" est un alias (la même chose appelée avec des noms différents) de "string". Donc techniquement, les deux instructions de code ci-dessous donneront le même résultat.

String s = "I am String";

ou

string s = "I am String";

De la même manière, il existe des alias pour d'autres types de données c #, comme indiqué ci-dessous: -

objet: System.Object , chaîne: System.String , bool: System.Boolean , octet: System.Byte , sbyte: System.SByte , bref: System.Int16 , etc.

Maintenant la question à un million de dollars du point de vue du programmeur Alors, quand utiliser "String" et "string"?

Première chose à faire pour éviter la confusion, utilisez l’un d’eux systématiquement. Mais du point de vue des meilleures pratiques lorsque vous faites une déclaration de variable, il est bon d’utiliser "string" (petit "s") et lorsque vous l’utilisez comme nom de classe, "String" (majuscule "S") est préférable.

Dans le code ci-dessous, le côté gauche est une déclaration de variable, déclarée à l'aide de "chaîne". A droite, nous appelons une méthode, donc "String" est plus sensé.

string s = String.ToUpper() ;



La string minuscule est un alias pour System.String . Ils sont les mêmes en C# .

Il existe un débat sur l'opportunité d'utiliser les types de types System ( System.Int32 , System.String , etc.) ou les C# aliases ( int , string , etc.). Personnellement, je pense que vous devriez utiliser les C# aliases , mais ce n’est que ma préférence personnelle.




Comme le disent les autres, ils sont identiques. Les règles StyleCop, par défaut, vous obligeront à utiliser string comme bonne pratique de style de code C #, sauf lors du référencement de fonctions statiques System.String , telles que String.Format , String.Join , String.Concat , etc.




Contrairement à ce qui semble être une pratique courante chez les autres programmeurs, je préfère String à string , juste pour souligner le fait que String est un type de référence, comme l'a mentionné Jon Skeet.




String ( System.String ) est une classe de la bibliothèque de classes de base. string (minuscule) est un travail réservé en C # qui est un alias pour System.String. Int32 vs int est une situation similaire au Boolean vs. bool . Ces mots clés spécifiques au langage C # vous permettent de déclarer des primitives dans un style similaire à C.




Arriver en retard à la fête: j'utilise les types CLR 100% du temps (enfin, sauf si je suis obligé d'utiliser le type C #, mais je ne me souviens pas de la date de la dernière fois).

J'ai commencé à faire cela il y a des années, selon les livres CLR de Ritchie. Il était logique pour moi que tous les langages CLR doivent en fin de compte pouvoir prendre en charge l'ensemble des types de CLR. Par conséquent, l'utilisation des types de CLR vous-même fournit un code plus clair et éventuellement plus "réutilisable".

Maintenant que je le fais depuis des années, c'est une habitude et j'aime la coloration que VS montre pour les types CLR.

Le seul inconvénient réel est que l'auto-complétion utilise le type C #. Je finis donc par ressaisir les types générés automatiquement pour spécifier le type CLR.

De plus, maintenant, quand je vois "int" ou "string", cela me semble vraiment faux, comme si je regardais le code C des années 1970.




C'est une question de convention, vraiment. string ressemble plus au style C / C ++. La convention générale consiste à utiliser les raccourcis fournis par la langue choisie (int / Int pour Int32 ). Cela vaut pour "objet" et decimal aussi.

Théoriquement, cela pourrait aider à transférer du code dans un futur standard 64 bits dans lequel "int" pourrait signifier Int64, mais ce n'est pas le point, et je m'attendrais à ce que tout assistant de mise à niveau modifie les intréférences de Int32toute façon pour être sûr.




Nouvelle réponse après 6 ans et 5 mois (procrastination).

While stringest un mot clé C # réservé qui a toujours une signification fixe, Stringn’est qu’un identifiant ordinaire qui peut désigner n'importe quoi. Selon les membres du type actuel, l'espace de nom actuel et les usingdirectives appliquées ainsi que leur emplacement Stringpeuvent être une valeur ou un type distinct de global::System.String.

Je vais donner deux exemples où les usingdirectives ne vont pas aider .

Premièrement, quand Stringest une valeur du type actuel (ou une variable locale):

class MySequence<TElement>
{
  public IEnumerable<TElement> String { get; set; }

  void Example()
  {
    var test = String.Format("Hello {0}.", DateTime.Today.DayOfWeek);
  }
}

Ce qui précède ne sera pas compilé car IEnumerable<>aucun membre non statique Formatn'est appelé et aucune méthode d'extension ne s'applique. Dans le cas ci-dessus, il peut toujours être possible d'utiliser Stringdans d'autres contextes où un type est la seule possibilité syntaxiquement. Par exemple, cela String local = "Hi mum!";pourrait être OK (selon l’espace de nom et les usingdirectives).

Pire: Dire String.Concat(someSequence)va probablement (selon usings) aller à la méthode d'extension Linq Enumerable.Concat. Cela n'ira pas à la méthode statique string.Concat.

Deuxièmement, quand Stringest un autre type , imbriqué dans le type actuel:

class MyPiano
{
  protected class String
  {
  }

  void Example()
  {
    var test1 = String.Format("Hello {0}.", DateTime.Today.DayOfWeek);
    String test2 = "Goodbye";
  }
}

Aucune instruction dans la Exampleméthode ne compile. Voici Stringtoujours un piano string , MyPiano.String. Aucun membre ( staticou pas) Formatn'existe sur celui-ci (ou n'est hérité de sa classe de base). Et la valeur "Goodbye"ne peut pas être convertie en elle.




chaîne est un mot clé et vous ne pouvez pas utiliser chaîne comme identifiant.

String n'est pas un mot clé et vous pouvez l'utiliser comme identifiant:

Exemple

string String = "I am a string";

Le mot clé stringest un alias car, System.Stringmis à part le mot clé problème, les deux sont exactement équivalents.

 typeof(string) == typeof(String) == typeof(System.String)



Il n'y a pas de différence entre les deux string, cependant, semble être l'option privilégiée lorsque l'on considère le code source d'autres développeurs.




Related