type - C#中字符串和字符串有什麼區別?
c# value type (20)
示例( 注意案例 ):
string s = "Hello world!";
String s = "Hello world!";
使用每種方法的準則是什麼? 有什麼區別 ?
C#是與CLR一起使用的語言。
string
是C#中的一個類型。
System.String
是CLR中的一種類型。
當您將C#與CLR一起使用時, string
將映射到System.String
。
從理論上講,您可以實現生成Java字節碼的C#編譯器。 這個編譯器的合理實現可能會將string
映射到java.lang.String
,以便與Java運行時庫進行互操作。
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#程序員所熟知的。
關於( int
, System.Int32
)等我可以這麼說。
System.String
是.NET字符串類 - 在C# string
是System.String
的別名 - 因此在使用中它們是相同的。
至於指導方針,我不會陷入困境,只是使用你想要的任何東西 - 生活中有更重要的事情,無論如何代碼都是一樣的。
如果你發現你自己構建系統,你需要指定你正在使用的整數的大小,因此傾向於使用Int16
, Int32
, UInt16
, UInt32
等,那麼使用String
可能看起來更自然 - 並且當它們在不同之間移動時.net語言可能會使事情更容易理解 - 否則我會使用string和int。
string
和String
在所有方面都相同(大寫“S”除外)。 無論如何都沒有性能影響。
由於語法高亮,大多數項目中首選小寫string
string
是System.String
的別名(或簡寫)。 這意味著,通過鍵入string
我們的意思是System.String
。 您可以在思考鏈接中閱讀更多內容: 'string'是System.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;
預先。
僅僅為了完整起見,這裡是相關信息的大腦轉儲......
正如其他人所說, string
是System.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
除了string
和object
,別名都是值類型。 decimal
是值類型,但不是CLR中的基本類型。 唯一沒有別名的原始類型是System.IntPtr
。
在規範中,值類型別名稱為“簡單類型”。 文字可用於每種簡單類型的常量值; 沒有其他值類型具有可用的文字形式。 (將其與允許DateTime
文字的VB進行比較,並且也具有別名。)
在某種情況下,您必須使用別名:明確指定枚舉的基礎類型時。 例如:
public enum Foo : UInt32 {} // Invalid
public enum Bar : uint {} // Valid
這只是規範定義枚舉聲明的方式問題 - 冒號之後的部分必須是整數型生成,這是sbyte
, byte
, short
, ushort
, int
, uint
, long
, ulong
, char
一個標記。 ..而不是例如變量聲明所使用的類型生產。 它並不表示任何其他差異。
最後,當談到使用它時:我個人在各處使用別名來實現,但是任何API都使用CLR類型。 你在實施方面使用它並不重要 - 你的團隊之間的一致性很好,但沒有人會關心。 另一方面,如果您在API中引用類型,則以語言中立的方式執行此操作,這一點非常重要。 名為ReadInt32
的方法是明確的,而名為ReadInt
的方法需要解釋。 例如,調用者可能正在使用為Int16
定義int
別名的語言。 .NET框架設計者已經遵循這種模式,在BitConverter
, BinaryReader
和Convert
類中有很好的例子。
兩者都是一樣的。 但從編碼指南的角度來看,最好使用string
而不是String
。 這是開發人員通常使用的。 例如,我不使用Int32
而是使用int
因為int
是Int32
別名
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可以映射到Int16或Int32 。 事實上,C ++ / CLI確實將long視為Int32 。 如果某人使用一種語言閱讀源代碼,如果他或她習慣於使用不同的編程語言進行編程,則很容易誤解代碼的意圖。 實際上,大多數語言甚至不會將long視為關鍵字,也不會編譯使用它的代碼。
- FCL有許多方法,它們將類型名稱作為其方法名稱的一部分。 例如, BinaryReader類型提供諸如ReadBoolean , ReadInt32 , ReadSingle等方法,而System.Convert類型提供諸如ToBoolean , ToInt32 , ToSingle等方法。 雖然編寫下面的代碼是合法的,但浮點線對我來說感覺非常不自然,並且線條不正確並不明顯:
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
但是,在考慮其他開發人員的源代碼時,似乎是首選方案。
是的,他們之間沒有區別,就像bool
和Boolean
。