c# vs typescript - Was ist der Unterschied zwischen String und String in C #?



15 Answers

Nur der Vollständigkeit halber hier ein Gehirnmüll von verwandten Informationen ...

Wie bereits erwähnt, ist string ein Alias ​​für System.String . Sie kompilieren zu demselben Code, so dass es zur Ausführungszeit keinerlei Unterschied gibt. Dies ist nur einer der Aliase in C #. Die vollständige Liste ist:

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

Abgesehen von string und object sind alle Aliase Werttypen. decimal ist ein Werttyp, jedoch kein primitiver Typ in der CLR. Der einzige primitive Typ ohne Alias ​​ist System.IntPtr .

In der Spezifikation werden die Werttyp-Aliasnamen als "einfache Typen" bezeichnet. Literale können für konstante Werte jedes einfachen Typs verwendet werden. Für andere Werttypen sind keine Literalformen verfügbar. (Vergleichen Sie dies mit VB, das DateTime Literale erlaubt, und hat auch einen Alias ​​dafür.)

Es gibt einen Umstand, in dem Sie die Aliase verwenden müssen: wenn Sie den zugrunde liegenden Typ einer Enumeration explizit angeben. Zum Beispiel:

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

Das ist nur eine Frage der Art und Weise, wie die Spezifikation Enumerationsdeklarationen definiert - der Teil nach dem Doppelpunkt muss die Produktion des integralen Typs sein , die ein Zeichen von sbyte , byte , short , ushort , int , uint , long , ulong , char . .. im Gegensatz zu einer Typproduktion, wie sie beispielsweise von Variablendeklarationen verwendet wird. Es zeigt keinen anderen Unterschied.

Schließlich, wenn es um die Verwendung geht: Ich persönlich benutze die Aliase überall für die Implementierung, aber den CLR-Typ für alle APIs. Es spielt eigentlich keine Rolle, was Sie in Bezug auf die Implementierung verwenden - die Konsistenz in Ihrem Team ist schön, aber niemand sonst kümmert es. Auf der anderen Seite ist es wirklich wichtig, dass Sie, wenn Sie sich auf einen Typ in einer API beziehen, dies sprachneutral tun. Eine Methode namens ReadInt32 ist eindeutig, wohingegen eine Methode namens ReadInt eine Interpretation erfordert. Der Anrufer könnte beispielsweise eine Sprache verwenden, die einen int Alias ​​für Int16 definiert. Die .NET-Framework-Designer sind diesem Muster gefolgt. Gute Beispiele hierfür sind die Klassen BitConverter , BinaryReader und Convert .

java stackoverflow 2012

Beispiel ( Fall beachten ):

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

Was sind die Richtlinien für die Verwendung von jedem? Und was sind die Unterschiede ?




Die beste Antwort, die ich je über die Verwendung der bereitgestellten Typenaliasnamen in C # gehört habe, stammt von Jeffrey Richter in seinem Buch CLR Via C # . Hier sind seine 3 Gründe:

  • Ich habe eine Reihe verwirrter Entwickler gesehen, die nicht wissen, ob sie String oder String in ihrem Code verwenden sollen. Da die Zeichenfolge (ein Schlüsselwort) in C # genau mit System.String (einem FCL-Typ) übereinstimmt, besteht kein Unterschied, und beide können verwendet werden.
  • In C # kann long zu System.Int64 zugeordnet werden , long jedoch in einer anderen Programmiersprache zu einem Int16 oder Int32 . In der Tat wird C ++ / CLI tatsächlich lange als Int32 behandelt . Jemand, der Quellcode in einer Sprache liest, kann leicht die Absicht des Codes falsch interpretieren, wenn er oder sie daran gewöhnt ist, in einer anderen Programmiersprache zu programmieren. Tatsächlich behandeln die meisten Sprachen nicht einmal lange ein Schlüsselwort und kompilieren auch keinen Code, der sie verwendet.
  • In der FCL gibt es viele Methoden, deren Typnamen Teil ihrer Methodennamen sind. Der Typ BinaryReader bietet beispielsweise Methoden wie ReadBoolean , ReadInt32 , ReadSingle usw. und der Typ System.Convert bietet Methoden wie ToBoolean , ToInt32 , ToSingle usw. an. Obwohl es legal ist, den folgenden Code zu schreiben, fühlt sich die Zeile mit Float für mich sehr unnatürlich an, und es ist nicht offensichtlich, dass die Zeile richtig ist:
BinaryReader br = new BinaryReader(...);
float val  = br.ReadSingle(); // OK, but feels unnatural
Single val = br.ReadSingle(); // OK and feels good

Also da hast du es. Ich denke, das sind alles wirklich gute Punkte. Ich finde jedoch nicht, dass ich Jeffreys Rat in meinem eigenen Code benutze. Vielleicht bin ich zu fest in meiner C # -Welt, aber am Ende versuche ich, meinen Code wie den Rahmencode aussehen zu lassen.




Es gibt einen Unterschied - Sie können String ohne using System; vorher.




System.String ist die .NET-Zeichenfolgenklasse - in C # string ist ein Alias ​​für System.String sind sie in der Verwendung identisch.

Was die Richtlinien angeht, würde ich mich nicht zu sehr festsetzen und einfach das verwenden, was Sie möchten - es gibt wichtigere Dinge im Leben und der Code wird auf jeden Fall derselbe sein.

Wenn Sie feststellen, dass Systeme erstellt werden, bei denen die Größe der von Ihnen verwendeten Ganzzahlen angegeben werden muss, und Sie dazu tendieren, Int16 , Int32 , UInt16 , UInt32 usw. zu verwenden, dann ist die Verwendung von String natürlicher, wenn Sie sich zwischen verschiedenen UInt32 bewegen .net-Sprachen könnten die Dinge verständlicher machen - ansonsten würde ich string und int verwenden.




string und String sind in jeder Hinsicht identisch (außer dem Großbuchstaben "S"). Es gibt keine Auswirkungen auf die Leistung.

In den meisten Projekten wird aufgrund der Hervorhebung der Syntax Kleinbuchstaben bevorzugt




Dieses YouTube- Video zeigt praktisch, wie sie sich unterscheiden.

Nun aber zu einer langen Textantwort.

Wenn wir über .NET sprechen, gibt es zwei verschiedene Dinge: .NET Framework und die anderen Sprachen ( C# , VB.NET usw.), die dieses Framework verwenden.

" System.String " oder "String" (Großbuchstabe "S") ist ein .NET Framework-Datentyp, während "String" ein C# System.String ist.

Kurz gesagt, "String" ist ein Alias ​​von "String". Technisch gesehen geben also beide Code-Anweisungen dieselbe Ausgabe aus.

String s = "I am String";

oder

string s = "I am String";

Auf die gleiche Weise gibt es Aliase für andere c # -Datentypen, wie unten gezeigt:

Objekt: System.Object , Zeichenfolge: System.String , System.String : System.Boolean , Byte: System.Byte , Sbyte: System.SByte , kurz: System.Int16 usw.

Jetzt die Millionen-Dollar-Frage aus Sicht des Programmierers. Wann also "String" und "String" verwenden?

Um Verwirrung zu vermeiden, verwenden Sie eine von ihnen konsequent. Aus Sicht der Best Practices ist es jedoch sinnvoll, bei der Variablendeklaration "string" (kleine "s") zu verwenden, und wenn Sie ihn als Klassennamen verwenden, wird "String" (groß "S") bevorzugt.

Im folgenden Code ist die linke Seite eine Variablendeklaration und wird mit "string" deklariert. Auf der rechten Seite nennen wir eine Methode, daher ist "String" sinnvoller.

string s = String.ToUpper() ;



System.String ist ein Alias ​​für System.String . Sie sind in C# .

Es gibt eine Debatte darüber, ob Sie die System.Int32 ( System.Int32 , System.String usw.) oder die C# aliases ( int , string usw.) verwenden sollten. Ich persönlich glaube, Sie sollten die C# aliases , aber das ist nur meine persönliche Präferenz.




Wie die anderen sagen, sind sie gleich. Die StyleCop-Regeln zwingen Sie standardmäßig zur Verwendung von string als String.Format String.Join C # -Code-Stil, außer wenn statische Funktionen von System.String werden, z. B. String.Format , String.Join , String.Concat usw.




Anders als bei anderen Programmierern allgemein üblich, bevorzuge ich String gegenüber string , nur um die Tatsache hervorzuheben, dass String ein Referenztyp ist, wie Jon Skeet erwähnt hat.




String ( System.String ) ist eine Klasse in der Basisklassenbibliothek. String (Kleinbuchstaben) ist eine in C # reservierte Arbeit, die ein Alias ​​für System.String ist. Int32 vs. Int ist eine ähnliche Situation wie Boolean vs. bool . Mit diesen für die C # -Sprache spezifischen Schlüsselwörtern können Sie Grundelemente in einem ähnlichen Stil wie C deklarieren.




Ich komme zu spät zur Party: Ich verwende die CLR-Typen zu 100% (naja, außer wenn ich gezwungen bin, den C # -Typ zu verwenden, aber ich erinnere mich nicht, wann das letzte Mal war).

Ich habe das schon vor Jahren mit den CLR-Büchern von Ritchie angefangen. Es hat für mich Sinn gemacht, dass alle CLR-Sprachen letztendlich die Menge der CLR-Typen unterstützen müssen, sodass die Verwendung der CLR-Typen selbst klareren und möglicherweise mehr "wiederverwendbaren" Code bietet.

Nun, da ich es seit Jahren mache, ist es eine Gewohnheit und ich mag die Farbgebung, die VS für die CLR-Typen zeigt.

Der einzige wirkliche Wermutstropfen ist, dass bei der automatischen Vervollständigung der Typ C # verwendet wird. Daher muss ich automatisch generierte Typen eingeben, um stattdessen den CLR-Typ anzugeben.

Wenn ich jetzt "int" oder "string" sehe, sieht es für mich einfach falsch aus, als würde ich auf den C-Code der 70er Jahre schauen.




Es ist wirklich eine Frage der Konvention. string sieht eher wie C / C ++ aus. Die allgemeine Konvention ist die Verwendung der von Ihnen gewählten Abkürzungen (int / Int für Int32 ). Dies gilt auch für "Objekt" und decimal .

Theoretisch könnte dies helfen, Code in einen zukünftigen 64-Bit-Standard zu portieren, in dem "int" bedeuten könnte Int64, aber das ist nicht der Punkt, und ich würde erwarten, dass jeder Upgrade-Assistent ohnehin irgendwelche intVerweise ändert , Int32nur um sicher zu sein.




Neue Antwort nach 6 Jahren und 5 Monaten (Verschleppung).

Während stringist ein reserviertes C # Schlüsselwort , das immer eine feste Bedeutung hat, Stringist nur eine gewöhnliche Kennung , das auf etwas verweisen konnte. Abhängig von den Mitgliedern des aktuellen Typs können der aktuelle Namespace und die angewendeten usingDirektiven sowie deren Anordnung Stringein Wert oder ein Typ sein, der sich von unterscheidet global::System.String.

Ich werde zwei Beispiele usinganführen, bei denen Richtlinien nicht helfen .

Erstens, wann Stringist ein Wert des aktuellen Typs (oder einer lokalen Variablen):

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

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

Das obige wird nicht kompiliert, da IEnumerable<>kein nicht statisches Member aufgerufen Formatwird und keine Erweiterungsmethoden angewendet werden. Im obigen Fall kann es immer noch möglich sein, sie Stringin anderen Zusammenhängen zu verwenden, in denen ein Typ die einzige Möglichkeit ist, syntaktisch. Zum Beispiel String local = "Hi mum!";könnte OK sein (abhängig von Namespace und usingDirektiven).

Schlimmer noch: Das Sprichwort String.Concat(someSequence)wird (abhängig von usings) wahrscheinlich zur Linq-Erweiterungsmethode gehen Enumerable.Concat. Es wird nicht die statische Methode verwendet string.Concat.

Zweitens, wenn Stringein anderer Typ im aktuellen Typ verschachtelt ist:

class MyPiano
{
  protected class String
  {
  }

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

Keine der Anweisungen in der ExampleMethode wird kompiliert. Hier Stringist immer ein Klavier - string , MyPiano.String. Es existiert kein Member ( staticoder nicht) Format(oder wird von seiner Basisklasse geerbt). Und der Wert "Goodbye"kann nicht in diesen Wert umgewandelt werden.




String ist ein Schlüsselwort und Sie können String nicht als Bezeichner verwenden.

String ist kein Schlüsselwort und Sie können es als Bezeichner verwenden:

Beispiel

string String = "I am a string";

Das Keyword stringist ein Alias ​​für System.Stringabgesehen von der Keyword-Ausgabe, die beiden sind genau gleichwertig.

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



Es gibt keinen Unterschied zwischen den beiden - stringscheint jedoch die bevorzugte Option zu sein, wenn man den Quellcode anderer Entwickler betrachtet.




Related