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




c# value type (20)

C#是與CLR一起使用的語言。

string是C#中的一個類型。

System.String是CLR中的一種類型。

當您將C#與CLR一起使用時, string將映射到System.String

從理論上講,您可以實現生成Java字節碼的C#編譯器。 這個編譯器的合理實現可能會將string映射到java.lang.String ,以便與Java運行時庫進行互操作。

示例( 注意案例 ):

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

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


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


此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() ;

string是C#for System.String的別名。
從技術上講,沒有區別。 這就像int System.Int32

就指南而言,通常建議您在引用對象時使用string

例如

string place = "world";

同樣,我認為如果您需要專門引用該類,通常建議使用String

例如

string greet = String.Format("Hello {0}!", place);

這是Microsoft在其示例中傾向於使用的樣式。

看來這個領域的指導可能已經改變,因為StyleCop現在強制使用C#特定的別名。


String代表System.String ,它是.NET Framework類型。 string System.String的C#語言中的別名 。 它們都被編譯為IL (中間語言)中的System.String ,因此沒有區別。 選擇你喜歡的並使用它。 如果你用C#編碼,我更喜歡string因為它是C#類型的別名,並且是C#程序員所熟知的。

關於intSystem.Int32等我可以這麼說。


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

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

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


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

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



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

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

string String = "I am a string";

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

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

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


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

正如其他人所說, 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類中有很好的例子。


兩者都是一樣的。 但從編碼指南的角度來看,最好使用string而不是String 。 這是開發人員通常使用的。 例如,我不使用Int32而是使用int因為intInt32別名

FYI“關鍵字字符串只是預定義類System.String的別名。” - C#語言規範4.2.3 http://msdn2.microsoft.com/En-US/library/aa691153.aspx


它已在上面介紹過; 但是,你不能在反射中使用string ; 你必須使用String


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


我想在Ritchers的書中將這個添加到lfousts回答中:

C#語言規範指出,“作為一種風格,使用關鍵字比使用完整的系統類型名稱更受歡迎。”我不同意語言規範; 我更喜歡使用FCL類型名稱並完全避免基本類型名稱。實際上,我希望編譯器甚至不提供原始類型名稱,並強迫開發人員使用FCL類型名稱。以下是我的理由:

在我閱讀完整段落之前,我沒有得到他的意見。


我聽說過在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#世界,但我最終試圖使我的代碼看起來像框架代碼。


沒有區別。

C#關鍵字string映射到.NET類型System.String- 它是一個保持語言命名約定的別名。

同樣,int映射到System.Int32


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

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

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

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

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


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


是的,他們之間沒有區別,就像boolBoolean





alias