spéciaux - string string c#
Quelle est la différence entre String et string en C#? (20)
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.
https://code.i-harness.com
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 ?
C # est un langage qui est utilisé avec le CLR.
string
est un type en C #.
System.String
est un type dans le CLR.
Lorsque vous utilisez C # avec la string
CLR, il est mappé à System.String
.
Théoriquement, vous pouvez implémenter un compilateur C # qui génère un bytecode Java. Une implémentation judicieuse de ce compilateur mapperait probablement la string
sur java.lang.String
afin d’interagir avec la bibliothèque d’exécution Java.
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 int
références de Int32
toute façon pour être sûr.
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.
Il n'y a pas de différence.
Le mot clé C # string
correspond au type .NET System.String
- il s'agit d'un alias qui respecte les conventions de dénomination du langage.
De même, les int
cartes pour System.Int32
.
Je préfère les types .NET
majuscules (plutôt que les alias) pour des raisons de formatage. Les types .NET
ont la même couleur que les autres types d'objet (les types de valeur sont des objets appropriés, après tout).
Les mots-clés conditionnels et de contrôle (tels que if
, switch
et return
) sont en minuscule et en bleu foncé (par défaut). Et je préférerais que le désaccord ne soit pas utilisé ni formaté.
Considérer:
String someString;
string anotherString;
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
.
L'utilisation des types de système facilite le portage entre C # et VB.Net, si vous êtes dans ce genre de chose.
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.
Les deux sont les même. Mais du point de vue des directives de codage, il est préférable d’utiliser string
au lieu de String
. C'est ce que les développeurs utilisent généralement. par exemple, au lieu d'utiliser Int32
nous utilisons int
comme int
est alias pour Int32
FYI «La chaîne de mots clés est simplement un alias de la classe prédéfinie System.String
.» - Spécification du langage C # 4.2.3 http://msdn2.microsoft.com/En-US/library/aa691153.aspx
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() ;
string
est un alias en C # pour System.String
.
Donc techniquement, il n'y a pas de différence. C'est comme int
vs System.Int32
.
En ce qui concerne les directives, il est généralement recommandé d’utiliser une string
chaque fois que vous faites référence à un objet.
par exemple
string place = "world";
De même, je pense qu'il est généralement recommandé d'utiliser String
si vous devez vous référer spécifiquement à la classe.
par exemple
string greet = String.Format("Hello {0}!", place);
C'est le style que Microsoft a tendance à utiliser dans leurs exemples .
Il semble que les indications dans ce domaine ont peut-être changé, car StyleCop impose désormais l'utilisation des alias spécifiques à C #.
String
représente System.String
et il s'agit d'un type .NET Framework. string
est un alias dans le langage C # pour System.String
. Les deux sont compilés dans System.String
en IL (langage intermédiaire), il n'y a donc pas de différence. Choisissez ce que vous aimez et utilisez-le. Si vous codez en C #, je préférerais string
car il s’agit d’un alias de type C # bien connu des programmeurs C #.
Je peux dire la même chose à propos de ( int
, System.Int32
), etc.
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
est un alias (ou un raccourci) de System.String
. Cela signifie que, en tapant string
nous voulions dire System.String
. Vous pouvez en lire plus dans think link: 'string' est un alias / raccourci de System.String.
string
est un mot réservé, mais String
n'est qu'un nom de classe. Cela signifie que la string
ne peut pas être utilisée seule comme nom de variable.
Si pour une raison quelconque vous vouliez une variable appelée chaîne , vous ne verriez que la première de ces compilations:
StringBuilder String = new StringBuilder(); // compiles
StringBuilder string = new StringBuilder(); // doesn't compile
Si vous voulez vraiment un nom de variable appelé chaîne, vous pouvez utiliser @
comme préfixe:
StringBuilder @string = new StringBuilder();
Autre différence critique: le dépassement de capacité les met en évidence différemment.
Il y a une différence : vous ne pouvez pas utiliser String
sans using System;
préalablement.
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é string
est un alias car, System.String
mis à 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.
Il y a une citation sur ce numéro du livre de Daniel Solis .
Tous les types prédéfinis sont directement mappés aux types .NET sous-jacents. Les noms de type C # (chaîne) sont simplement des alias pour les types .NET (String ou System.String), de sorte que l'utilisation des noms .NET fonctionne parfaitement syntaxiquement, bien que cela soit déconseillé. Dans un programme C #, vous devez utiliser les noms C # plutôt que les noms .NET.