type value c# C#中字符串和字符串有什麼區別?



15 Answers

僅僅為了完整起見,這裡是相關信息的大腦轉儲......

正如其他人所說, stringSystem.String的別名。 它們編譯為相同的代碼,因此在執行時沒有任何區別。 這只是C#中的別名之一。 完整清單是:

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

除了stringobject ,別名都是值類型。 decimal是值類型,但不是CLR中的基本類型。 唯一沒有別名的原始類型是System.IntPtr

在規範中,值類型別名稱為“簡單類型”。 文字可用於每種簡單類型的常量值; 沒有其他值類型具有可用的文字形式。 (將其與允許DateTime文字的VB進行比較,並且也具有別名。)

在某種情況下,您必須使用別名:明確指定枚舉的基礎類型時。 例如:

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

這只是規範定義枚舉聲明的方式問題 - 冒號之後的部分必須是整數型生成,這是sbytebyteshortushortintuintlongulongchar一個標記。 ..而不是例如變量聲明所使用的類型生產。 它並不表示任何其他差異。

最後,當談到使用它時:我個人在各處使用別名來實現,但是任何API都使用CLR類型。 你在實施方面使用它並不重要 - 你的團隊之間的一致性很好,但沒有人會關心。 另一方面,如果您在API中引用類型,則以語言中立的方式執行此操作,這一點非常重要。 名為ReadInt32的方法是明確的,而名為ReadInt的方法需要解釋。 例如,調用者可能正在使用為Int16定義int別名的語言。 .NET框架設計者已經遵循這種模式,在BitConverterBinaryReaderConvert類中有很好的例子。

c# .net string types alias

示例( 注意案例 ):

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

使用每種方法的準則是什麼? 有什麼區別




我聽說過在C#中使用提供的類型別名的最佳答案來自Jeffrey Richter在他的書CLR Via C#中 。 以下是他的3個理由:

  • 我見過許多開發人員感到困惑,不知道是否在代碼中使用字符串字符串 。 因為在C#中,字符串(關鍵字)完全映射到System.String(一種FCL類型),所以沒有區別,可以使用它們。
  • 在C#中, 映射到System.Int64 ,但是在不同的編程語言中, long可以映射到Int16Int32 。 事實上,C ++ / CLI確實將long視為Int32 。 如果某人使用一種語言閱讀源代碼,如果他或她習慣於使用不同的編程語言進行編程,則很容易誤解代碼的意圖。 實際上,大多數語言甚至不會將long視為關鍵字,也不會編譯使用它的代碼。
  • FCL有許多方法,它們將類型名稱作為其方法名稱的一部分。 例如, BinaryReader類型提供諸如ReadBooleanReadInt32ReadSingle等方法,而System.Convert類型提供諸如ToBooleanToInt32ToSingle等方法。 雖然編寫下面的代碼是合法的,但浮點線對我來說感覺非常不自然,並且線條不正確並不明顯:
BinaryReader br = new BinaryReader(...);
float val  = br.ReadSingle(); // OK, but feels unnatural
Single val = br.ReadSingle(); // OK and feels good

所以你有它。 我認為這些都非常好。 但是,我發現自己在自己的代碼中沒有使用Jeffrey的建議。 也許我太困在我的C#世界,但我最終試圖使我的代碼看起來像框架代碼。




有一個區別 - 你不能在不使用using System;情況下使用String using System; 預先。




System.String是.NET字符串類 - 在C# stringSystem.String的別名 - 因此在使用中它們是相同的。

至於指導方針,我不會陷入困境,只是使用你想要的任何東西 - 生活中有更重要的事情,無論如何代碼都是一樣的。

如果你發現你自己構建系統,你需要指定你正在使用的整數的大小,因此傾向於使用Int16Int32UInt16UInt32等,那麼使用String可能看起來更自然 - 並且當它們在不同之間移動時.net語言可能會使事情更容易理解 - 否則我會使用string和int。




stringString在所有方面都相同(大寫“S”除外)。 無論如何都沒有性能影響。

由於語法高亮,大多數項目中首選小寫string




此YouTube視頻實際上展示了它們的不同之處。

但現在需要很長的文字答案。

當我們談論.NET ,有兩種不同的東西,一種是.NET框架,另一種是使用該框架的語言( C#VB.NET等)。

System.String ”又名“String”(大寫“S”)是.NET框架數據類型,而“string”是C#數據類型。

簡而言之,“String”是“string”的別名(使用不同的名稱調用相同的東西)。 因此從技術上講,下面的代碼語句都會提供相同的輸出。

String s = "I am String";

要么

string s = "I am String";

同樣,其他c#數據類型也有別名,如下所示: -

object: System.Object ,string: System.String ,bool: System.Boolean ,byte: System.Byte ,sbyte: System.SByte ,short: System.Int16等等

現在從程序員的角度來看百萬美元的問題那麼何時使用“String”和“string”?

避免混淆的第一件事是始終如一地使用其中一個。 但是從最佳實踐角度來看,當你進行變量聲明時,最好使用“string”(小“s”),當你使用它作為類名時,首選“String”(大寫“S”)。

在下面的代碼中,左側是變量聲明,它使用“string”聲明。 在右側,我們調用一種方法,因此“字符串”更明智。

string s = String.ToUpper() ;



小寫stringSystem.String的別名。 它們在C#中是相同的。

關於是否應該使用系統類型( System.Int32System.String等)類型或C# aliasesintstring等)存在爭議。 我個人認為你應該使用C# aliases ,但這只是我個人的偏好。




正如其他人所說,他們是一樣的。 默認情況下,StyleCop規則將強制您使用string作為C#代碼樣式的最佳實踐,除非引用System.String靜態函數,例如String.FormatString.JoinString.Concat等...




對於其他程序員似乎常見的做法,我更喜歡String over string ,只是為了強調String是一個引用類型,正如Jon Skeet所提到的那樣。




String( System.String )是基類庫中的一個類。 string(小寫)是C#中的保留工作,它是System.String的別名。 Int32 vs int與Boolean vs. bool類似。 這些特定於C#語言的關鍵字使您能夠以類似於C的樣式聲明基元。




聚會遲到:我100%使用CLR類型(好吧,除非被迫使用C#類型,但我不記得最後一次是什麼時候)。

根據Ritchie的CLR書籍,我最初幾年前開始做這件事。 我認為所有CLR語言最終都必須能夠支持CLR類型集合,因此使用CLR類型本身提供了更清晰,可能更“可重用”的代碼。

現在我已經做了多年,這是一種習慣,我喜歡VS為CLR類型顯示的顏色。

唯一真正的失敗是自動完成使用C#類型,所以我最終重新鍵入自動生成的類型來指定CLR類型。

而且,現在,當我看到“int”或“string”時,我看起來真的不對,就像我在看1970年的C代碼一樣。




真的,這是一個慣例問題。string看起來更像是C / C ++風格。一般約定是使用您選擇的語言提供的任何快捷方式(int / Int for Int32)。這也適用於“對象” decimal

從理論上講,這可能有助於將代碼移植到未來的64位標準中,其中“int”可能意味著Int64,但這不是重點,我希望任何升級嚮導都可以更改任何int引用,Int32只是為了安全。




6年零5個月後的新答案(拖延)。

雖然string保留的C#關鍵字始終具有固定含義,但String它只是一個可以引用任何內容的普通標識符。根據當前類型的成員,當前命名空間和應用的using指令及其位置String可以是不同的值或類型global::System.String

我將提供兩個using指令無效的例子。

首先,當String是一個的當前類型(或局部變量)的:

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

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

以上將不會編譯,因為IEnumerable<>沒有調用非靜態成員Format,並且不應用擴展方法。在上述情況下,仍然可以String在其他上下文中使用,其中類型是語法上唯一的可能性。例如,String local = "Hi mum!";可以是OK(取決於命名空間和using指令)。

更糟糕的是:說String.Concat(someSequence)可能(取決於usings)轉到Linq擴展方法Enumerable.Concat。它不會轉到靜態方法string.Concat

其次,當String是另一種類型時,嵌套在當前類型中:

class MyPiano
{
  protected class String
  {
  }

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

Example方法中的任何一個語句都沒有編譯。這String始終是一個鋼琴stringMyPiano.String。沒有成員(static或不Format存在)(或從其基類繼承)。而且價值"Goodbye"無法轉化為它。




string是關鍵字,您不能使用string作為標識符。

String不是關鍵字,您可以將其用作標識符:

string String = "I am a string";

除關鍵字問題外,關鍵字string是別名System.String,兩者完全等效。

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



兩者之間沒有區別 - string但是,在考慮其他開發人員的源代碼時,似乎是首選方案。






Related