string和C#中的string有什么区别?

示例( 注意案例 ):

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

什么是使用每个指导方针? 有什么区别?

string是C#中System.String的别名。 所以在技术上,没有什么区别。 这就像int System.Int32

就指导原则而言,我认为通常build议在任何时候使用string来引用对象。

例如

 string place = "world"; 

同样,我认为通常build议使用String如果你需要专门提到类。

例如

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

这是微软在他们的例子中倾向于使用的风格。


看来这个领域的指导可能已经改变了,因为StyleCop现在强制使用C#特定的别名。

只是为了完整性,这是一个相关信息的大脑转储…

正如其他人所指出的, 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 ,别名都是值types。 decimal是一个值types,但不是CLR中的基本types。 唯一没有别名的基本types是System.IntPtr

在规范中,值types别名被称为“简单types”。 文字可以用于每个简单types的常量值; 没有其他值types可用文字forms。 (比较这与VB,它允许DateTime文字,也有一个别名。)

有一种情况需要使用别名:明确指定枚举的基础types。 例如:

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

这只是规范定义枚举声明的方式的问题 – 冒号之后的部分必须是整型生产,它是sbytebyteshortushortintuintlongulongchar一个标记。例如,与variables声明所使用的types生产相反。 这并没有表明有任何其他的差异。

最后,当涉及到使用哪个:我个人使用别名来实现,但CLRtypes的任何API。 在实施方面,使用真的没关系 – 团队之间的一致性很好,但没有其他人会关心。 另一方面,如果您在API中引用某个types,则以语言中立的方式进行操作是非常重要的。 称为ReadInt32的方法是明确的,而称为ReadInt的方法需要解释。 例如,调用者可以使用为Int16定义一个int别名的语言。 .NET框架devise者遵循这种模式,在BitConverterBinaryReaderConvert类中都有很好的例子。

String代表System.String ,它是一个.NET Frameworktypes。 string System.String的C#语言中的别名 。 它们都被编译为IL (中级语言)中的System.String ,所以没有区别。 select你喜欢和使用的。 如果你用C#编写代码,我宁愿使用string因为它是C#types的别名,并且是C#程序员所熟知的。

我可以说相同的intSystem.Int32等。

我从来没有听说过在C#中使用提供的types别名的最佳答案来自Jeffrey Richter在他的书CLR Via C#中 。 这是他的三个原因:

  • 我看到一些开发人员感到困惑,不知道是否在代码中使用stringstring 。 因为在C#中,string(一个关键字)完全映射到System.String(一个FCLtypes),所以没有区别,可以使用。
  • 在C#中, long映射到System.Int64 ,但是使用不同的编程语言, long可以映射到Int16Int32 。 实际上,C ++ / CLI实际上只把Int32作为一个对象。 有人用一种语言阅读源代码,如果他们习惯用不同的编程语言编程,就很容易误解代码的意图。 实际上,大多数语言甚至不会将长时间视为关键字,也不会编译使用它的代码。
  • FCL有许多方法名称都是types名称的一部分。 例如, BinaryReadertypes提供诸如ReadBooleanReadInt32ReadSingle等方法,而System.Converttypes则提供ToBooleanToInt32ToSingle等方法。 虽然写下面的代码是合法的,但是带有float的行对我来说感觉非常不自然,而且行不正确:
 BinaryReader br = new BinaryReader(...); float val = br.ReadSingle(); // Ok, but feels unnatural Single val = br.ReadSingle(); // OK and feels good 

所以你有它。 我认为这些都是非常好的一点。 但是,我并没有发现自己在自己的代码中使用Jeffrey的build议。 也许我太困在我的C#世界,但我最终试图使我的代码看起来像框架代码。

string是一个保留字,但是String只是一个类名。 这意味着string本身不能用作variables名称。

如果由于某种原因你想要一个名为string的variables,你只会看到这些编译的第一个:

 StringBuilder String = new StringBuilder(); // compiles StringBuilder string = new StringBuilder(); // doesn't compile 

如果你真的想要一个叫做string的variables名,你可以使用@作为前缀:

 StringBuilder @string = new StringBuilder(); 

另一个关键差异:堆栈溢出突出显示他们不同

有一个区别 – 你不能使用String而不using System; 预先。

它已被覆盖在上面; 但是,您不能在reflection中使用string ; 你必须使用String

Valters,就我所知,你不能以stringint等formsbuild立全局别名。 但是,可以using关键字为types和名称空间执行更多的本地化别名。

例如

 using str = System.String; using strDict = System.Collections.Generic.Dictionary<string, string>; //... str s = "Now you've got another alias for string!"; var d = new strDict(); 

看到这里: 使用指令(C#参考)

System.String是.netstring类 – 在C#中stringSystem.String的别名 – 所以在使用中它们是相同的。

至于指导原则,我不会太陷入困境,只要用你自己的想法 – 生活中有更重要的事情,代码将会是相同的。

如果你发现自己构build的系统需要指定你使用的整数的大小,所以倾向于使用Int16Int32UInt16UInt32等,那么使用String可能看起来更自然 – 而当在不同的.net语言可能会让事情变得更容易理解,否则我会使用string和int。

stringString在所有方面都是相同的(除了大写的“S”)。 这两种方式都没有任何性能影响。

由于语法高亮,大多数项目都使用小写string

出于格式化原因,我更喜欢大写的.NETtypes(而不是别名)。 .NETtypes与其他对象types颜色相同(值types毕竟是适当的对象)。

有条件和控制关键字(如ifswitchreturn )是小写字母,并且是深蓝色的(默认情况下)。 我宁愿不要在使用和格式上存在分歧。

考虑:

 String someString; string anotherString; 

C#是一种与CLR一起使用的语言。

string是C#中的一个types。

System.String是CLR中的一个types。

当您使用C#时,CLR string将被映射到System.String

理论上,你可以实现一个生成Java字节码的C#编译器。 这个编译器的一个明智的实现可能会将string映射到java.lang.String以便与Java运行时库进行交互操作。

这个YouTubevideo实际上演示了它们的不同之处。

但是现在需要长时间的文字回答。

当我们谈论.NET ,有两个不同的东西,一个是.NET框架,另一个是使用该框架的语言( C#VB.NET等)。

在这里输入图像描述

System.String ”aka“String”(大写“S”)是一个.NET框架数据types,而“string”是一个C#数据types。

在这里输入图像描述

简而言之,“string”是“string”的别名(称为不同名称的同一事物)。 所以在技术上,下面的代码语句会给出相同的输出。

 String s = "I am String"; 

要么

 string s = "I am String"; 

以同样的方式,有其他c#数据types的别名,如下所示: –

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

现在从程序员的angular度来看百万美元的问题那么何时使用“string”和“string”呢?

首先避免混淆使用其中之一。 但从最佳实践的angular度来看,当你做variables声明的时候,最好使用“string”(小的“s”),当你使用它作为类名时,首选“String”(大写“S”)。

在下面的代码中,左边是一个variables声明,并使用“string”声明。 在右侧,我们正在调用一个方法,所以“String”更明智。

 string s = String.ToUpper() ; 

string只是System.String的别名。 编译器会对它们进行相同的处理。

唯一实际的区别是语法突出显示,如果您使用String则必须使用using System编写。

小写stringSystem.String的别名。 他们在C#中是一样的。

关于是否应该使用Systemtypes( System.Int32System.String等)types或C# aliasesintstring等)存在争议。 我个人认为你应该使用C# aliases ,但这只是我个人的偏好。

两者都是一样的。 但是从编码准则的angular度来看,最好使用string而不是String 。 这是一般开发人员使用的。 例如,而不是使用Int32我们使用int作为intInt32别名

仅供参考“关键字string只是预定义的类System.String的别名” – C#语言规范4.2.3 http://msdn2.microsoft.com/zh-cn/library/aa691153.aspx

正如其他人所说,他们是一样的。 StyleCop规则,默认情况下,将强制您使用string作为C#代码样式的最佳做法,除非引用System.String静态函数,如String.FormatString.JoinString.Concat等…

使用系统types可以更轻松地在C#和VB.Net之间进行移植,如果您遇到这种情况。

与其他程序员之间似乎很常见的做法相比,我更喜欢String over string ,只是为了强调String是一个引用types的事实,正如Jon Skeet所说的。

stringSystem.String的别名(或简写)。 这意味着,通过inputstring我们的意思是System.String 。 您可以在think link中阅读更多: 'string'是System.String的别名/简写。

String( System.String )是基类库中的一个类。 string(小写)是C#中保留的工作,它是System.String的别名。 Int32与int的情况与Boolean vs. bool相似。 这些C#语言特定的关键字使您能够以类似于C的风格声明原语。

String不是关键字,可以用作标识符,而string是关键字,不能用作标识符。 而在function上来看都是一样的。

晚会迟到:我使用CLRtypes100%的时间(当然,除非强制使用C#types,但我不记得上次是什么时候)。

根据Ritchie的CLR书籍,我最初是在几年前开始的。 对我来说,所有CLR语言最终都必须能够支持CLRtypes,因此使用CLRtypes可以提供更清晰,更可重用的代码。

现在我已经做了多年,这是一种习惯,我喜欢VS为CLRtypes显示的着色。

唯一真正的地方是自动完成使用C#types,所以我最终重新input自动生成的types来指定CLRtypes。

此外,现在,当我看到“int”或“string”时,对我来说看起来确实是错误的,就像我在看1970年代的C代码一样。

我只是想补充一点,从Ritchers的书中回答:

C#语言规范指出:“就风格而言,使用关键字比使用完整的系统types名称更受欢迎。”我不同意语言规范。 我更喜欢使用FCLtypes名称,并完全避免原始types名称。 事实上,我希望编译器甚至不提供原始types名称,并强迫开发人员使用FCLtypes名称。 这是我的原因:

在阅读完整段落之前,我没有得到他的意见。

这是一个惯例,真的。 “string”看起来更像C / C ++风格。 The general convention is to use whatever shortcuts your chosen language has provided (int/Int for Int32). This goes for "object" and "decimal" as well.

Theoretically this could help to port code into some future 64-bit standard in which "int" might mean Int64, but that's not the point, and I would expect any upgrade wizard to change any "int" references to "Int32" anyway just to be safe.

没有区别。

The C# keyword string maps to the .NET type System.String – it is an alias that keeps to the naming conventions of the language.

Similarly, int maps to System.Int32 .

New answer after 6 years and 5 months (procrastination).

While string is a reserved C# keyword that always has a fixed meaning, String is just an ordinary identifier which could refer to anything. Depending on members of the current type, the current namespace and the applied using directives and their placement, String could be a value or a type distinct from global::System.String .

I shall provide two examples where using directives will not help .


First, when String is a value of the current type (or a local variable):

 class MySequence<TElement> { public IEnumerable<TElement> String { get; set; } void Example() { var test = String.Format("Hello {0}.", DateTime.Today.DayOfWeek); } } 

The above will not compile because IEnumerable<> does not have a non-static member called Format , and no extension methods apply. In the above case, it may still be possible to use String in other contexts where a type is the only possibility syntactically. For example String local = "Hi mum!"; could be OK (depending on namespace and using directives).

Worse: Saying String.Concat(someSequence) will likely (depending on using s) go to the Linq extension method Enumerable.Concat . It will not go to the static method string.Concat .


Secondly, when String is another type , nested inside the current type:

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

Neither statement in the Example method compiles. Here String is always a piano string , MyPiano.String . No member ( static or not) Format exists on it (or is inherited from its base class). And the value "Goodbye" cannot be converted into it.

Yes, that's no difference between them, just like the bool and Boolean .

string is a keyword, and you can't use string as an identifier.

String is not a keyword, and you can use it as an identifier:

 string String = "I am a string"; 

The keyword string is an alias for System.String aside from the keyword issue, the two are exactly equivalent.

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

There's a quote on this issue from Daniel Solis' book .

All the predefined types are mapped directly to underlying .NET types. The C# type names (string) are simply aliases for the .NET types (String or System.String), so using the .NET names works fine syntactically, although this is discouraged. Within a C# program, you should use the C# names rather than the .NET names.