C＃中字符串和字符串有什么区别？

Example (note the case):

示例(注意案例):

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

What are the guidelines for the use of each? And what are the differences?

每种使用的准则是什么?有什么区别?

61 个解决方案

#1

string is an alias in C# for System.String.
So technically, there is no difference. It's like int vs. System.Int32.

string是C#for System.String中的别名。从技术上讲,没有区别。这就像int与System.Int32。

As far as guidelines, it's generally recommended to use string any time you're referring to an object.

就指南而言,通常建议您在引用对象时使用字符串。

e.g.

string place = "world";

Likewise, I think it's generally recommended to use String if you need to refer specifically to the class.

同样,我认为如果您需要专门引用该类,通常建议使用String。

e.g.

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

This is the style that Microsoft tends to use in their examples.

It appears that the guidance in this area may have changed, as StyleCop now enforces the use of the C# specific aliases.

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

#2

Just for the sake of completeness, here's a brain dump of related information...

只是为了完整起见,这里是相关信息的大脑转储......

As others have noted, string is an alias for System.String. They compile to the same code, so at execution time there is no difference whatsoever. This is just one of the aliases in C#. The complete list is:

正如其他人所说,string是System.String的别名。它们编译为相同的代码,因此在执行时没有任何区别。这只是C#中的别名之一。完整清单是:

object:  System.Objectstring:  System.Stringbool:    System.Booleanbyte:    System.Bytesbyte:   System.SByteshort:   System.Int16ushort:  System.UInt16int:     System.Int32uint:    System.UInt32long:    System.Int64ulong:   System.UInt64float:   System.Singledouble:  System.Doubledecimal: System.Decimalchar:    System.Char

Apart from string and object, the aliases are all to value types. decimal is a value type, but not a primitive type in the CLR. The only primitive type which doesn't have an alias is System.IntPtr.

除了字符串和对象之外,别名都是值类型。 decimal是值类型,但不是CLR中的基本类型。唯一没有别名的原始类型是System.IntPtr。

In the spec, the value type aliases are known as "simple types". Literals can be used for constant values of every simple type; no other value types have literal forms available. (Compare this with VB, which allows DateTime literals, and has an alias for it too.)

在规范中,值类型别名称为“简单类型”。文字可用于每种简单类型的常量值;没有其他值类型具有可用的文字形式。 (将其与允许DateTime文字的VB进行比较,并且也具有别名。)

There is one circumstance in which you have to use the aliases: when explicitly specifying an enum's underlying type. For instance:

在某种情况下,您必须使用别名:明确指定枚举的基础类型时。例如:

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

That's just a matter of the way the spec defines enum declarations - the part after the colon has to be the integral-type production, which is one token of sbyte, byte, short, ushort, int, uint, long, ulong, char... as opposed to a type production as used by variable declarations for example. It doesn't indicate any other difference.

这只是规范定义枚举声明的方式问题 - 冒号之后的部分必须是整数型生成,这是sbyte,byte,short,ushort,int,uint,long,ulong,char的一个标记。 ..而不是例如变量声明所使用的类型生产。它并不表示任何其他差异。

Finally, when it comes to which to use: personally I use the aliases everywhere for the implementation, but the CLR type for any APIs. It really doesn't matter too much which you use in terms of implementation - consistency among your team is nice, but no-one else is going to care. On the other hand, it's genuinely important that if you refer to a type in an API, you do so in a language neutral way. A method called ReadInt32 is unambiguous, whereas a method called ReadInt requires interpretation. The caller could be using a language which defines an int alias for Int16, for example. The .NET framework designers have followed this pattern, good examples being in the BitConverter, BinaryReader and Convert classes.

最后,当涉及到使用哪个时:我个人在各处使用别名来实现,但是任何API都使用CLR类型。你在实施方面使用它并不重要 - 团队之间的一致性很好,但没有人会关心。另一方面,如果您在API中引用类型,则以语言中立的方式执行此操作,这一点非常重要。名为ReadInt32的方法是明确的,而名为ReadInt的方法需要解释。例如,调用者可能正在使用为Int16定义int别名的语言。 .NET框架设计者已经遵循这种模式,在BitConverter,BinaryReader和Convert类中有很好的例子。

#3

String stands for System.String and it is a .NET Framework type. string is an alias in the C# language for System.String. Both of them are compiled to System.String in IL (Intermediate Language), so there is no difference. Choose what you like and use that. If you code in C#, I'd prefer string as it's a C# type alias and well-known by C# programmers.

String代表System.String,它是.NET Framework类型。 string是System.String的C#语言中的别名。它们都被编译为IL(中间语言)中的System.String,因此没有区别。选择你喜欢的并使用它。如果你用C#编写代码,我更喜欢字符串,因为它是C#类型的别名,并且是C#程序员所熟知的。

I can say the same about (int, System.Int32) etc..

我可以说同样的(int,System.Int32)等。

#4

The best answer I have ever heard about using the provided type aliases in C# comes from Jeffrey Richter in his book CLR Via C#. Here are his 3 reasons:

我听说过在C#中使用提供的类型别名的最佳答案来自Jeffrey Richter在他的书“CLR Via C#”中。以下是他的3个理由:

• I've seen a number of developers confused, not knowing whether to use string or String in their code. Because in C# the string (a keyword) maps exactly to System.String (an FCL type), there is no difference and either can be used.

我看到许多开发人员感到困惑,不知道是否在他们的代码中使用字符串或字符串。因为在C#中,字符串(关键字)完全映射到System.String(一种FCL类型),所以没有区别,任何一种都可以使用。

• In C#, long maps to System.Int64, but in a different programming language, long could map to an Int16 or Int32. In fact, C++/CLI does in fact treat long as an Int32. Someone reading source code in one language could easily misinterpret the code's intention if he or she were used to programming in a different programming language. In fact, most languages won't even treat long as a keyword and won't compile code that uses it.

在C#中,长映射到System.Int64,但是在不同的编程语言中,long可以映射到Int16或Int32。事实上,C ++ / CLI确实将long视为Int32。如果某人使用一种语言阅读源代码,如果他或她习惯于使用不同的编程语言进行编程,则很容易误解代码的意图。事实上,大多数语言甚至不会将long视为关键字,也不会编译使用它的代码。

• The FCL has many methods that have type names as part of their method names. For example, the BinaryReader type offers methods such as ReadBoolean, ReadInt32, ReadSingle, and so on, and the System.Convert type offers methods such as ToBoolean, ToInt32, ToSingle, and so on. Although it's legal to write the following code, the line with float feels very unnatural to me, and it's not obvious that the line is correct:

FCL有许多方法,它们将类型名称作为其方法名称的一部分。例如,BinaryReader类型提供诸如ReadBoolean,ReadInt32,ReadSingle等方法,而System.Convert类型提供诸如ToBoolean,ToInt32,ToSingle等方法。虽然编写下面的代码是合法的,但浮点线对我来说感觉非常不自然,并且线条不正确并不明显:

BinaryReader br = new BinaryReader(...);float val  = br.ReadSingle(); // OK, but feels unnaturalSingle val = br.ReadSingle(); // OK and feels good

So there you have it. I think these are all really good points. I however, don't find myself using Jeffrey's advice in my own code. Maybe I am too stuck in my C# world but I end up trying to make my code look like the framework code.

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

#5

string is a reserved word, but String is just a class name. This means that string cannot be used as a variable name by itself.

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

If for some reason you wanted a variable called string, you'd see only the first of these compiles:

如果由于某种原因你想要一个名为string的变量,你只能看到第一个这样的编译:

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

If you really want a variable name called string you can use @ as a prefix:

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

StringBuilder @string = new StringBuilder();

Another critical difference: Stack Overflow highlights them differently.

另一个重要区别:Stack Overflow以不同的方式强调它们。

#6

There is one difference - you can't use String without using System; beforehand.

有一个区别 - 你不能在不使用System的情况下使用String;预先。

#7

It's been covered above; however, you can't use string in reflection; you must use String.

它已被覆盖在上面;但是,你不能在反射中使用字符串;你必须使用String。

#8

System.String is the .NET string class - in C# string is an alias for System.String - so in use they are the same.

System.String是.NET字符串类 - 在C#字符串中是System.String的别名 - 因此在使用它们时是相同的。

As for guidelines I wouldn't get too bogged down and just use whichever you feel like - there are more important things in life and the code is going to be the same anyway.

至于指导方针,我不会陷入困境,只是使用你想要的任何东西 - 生活中有更重要的事情,无论如何代码都是一样的。

If you find yourselves building systems where it is necessary to specify the size of the integers you are using and so tend to use Int16, Int32, UInt16, UInt32 etc. then it might look more natural to use String - and when moving around between different .net languages it might make things more understandable - otherwise I would use string and int.

如果你发现你自己构建系统需要指定你正在使用的整数的大小,所以倾向于使用Int16,Int32,UInt16,UInt32等,那么使用String可能看起来更自然 - 并且当它们之间移动时.net语言可能会让事情变得更容易理解 - 否则我会使用string和int。

#9

I prefer the capitalized .NET types (rather than the aliases) for formatting reasons. The .NET types are colored the same as other object types (the value types are proper objects, after all).

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

Conditional and control keywords (like if, switch, and return) are lowercase and colored dark blue (by default). And I would rather not have the disagreement in use and format.

条件和控制关键字(如if,switch和return)为小写且为深蓝色(默认情况下)。我宁愿在使用和格式方面没有分歧。

Consider:

String someString; string anotherString; 

#10

string and String are identical in all ways (except the uppercase "S"). There are no performance implications either way.

string和String在所有方面都相同(大写“S”除外)。无论如何都没有性能影响。

Lowercase string is preferred in most projects due to the syntax highlighting

由于语法高亮,大多数项目中首选小写字符串

#11

C# is a language which is used together with the CLR.

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

string is a type in C#.

string是C#中的一个类型。

System.String is a type in the CLR.

System.String是CLR中的一种类型。

When you use C# together with the CLR string will be mapped to System.String.

当您将C#与CLR一起使用时,字符串将映射到System.String。

Theoretically, you could implement a C#-compiler that generated Java bytecode. A sensible implementation of this compiler would probably map string to java.lang.String in order to interoperate with the Java runtime library.

从理论上讲,您可以实现生成Java字节码的C#编译器。这个编译器的合理实现可能会将字符串映射到java.lang.String,以便与Java运行时库进行互操作。

#12

This YouTube video demonstrates practically how they differ.

此YouTube视频实际上展示了它们的不同之处。

But now for a long textual answer.

但现在需要长篇文章答案。

When we talk about .NET there are two different things one there is .NET framework and the other there are languages ( C# , VB.NET etc) which use that framework.

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

"System.String" a.k.a "String" ( capital "S") is a .NET framework data type while "string" is a C# data type.

“System.String”a.k.a“String”(大写“S”)是.NET框架数据类型,而“string”是C#数据类型。

In short "String" is an alias ( the same thing called with different names) of "string". So technically both the below code statements will give the same output.

简而言之,“String”是“string”的别名(使用不同名称调用相同的东西)。因此从技术上讲,下面的代码语句都会提供相同的输出。

String s = "I am String";

or

string s = "I am String";

In the same way there are aliases for other c# data type as shown below:-

同样,其他c#数据类型也有别名,如下所示: -

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

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

Now the million dollar question from programmer's point of view So when to use "String" and "string"?

从程序员的角度来看,这个百万美元的问题那么何时使用“String”和“string”?

First thing to avoid confusion use one of them consistently. But from best practices perspective when you do variable declaration it's good to use "string" ( small "s") and when you are using it as a class name then "String" ( capital "S") is preferred.

避免混淆的第一件事是始终如一地使用其中一个。但是从最佳实践角度来看,当你进行变量声明时,最好使用“string”(小“s”),当你使用它作为类名时,首选“String”(大写“S”)。

In the below code the left hand side is a variable declaration and it declared using "string". At the right hand side we are calling a method so "String" is more sensible.

在下面的代码中,左侧是变量声明,它使用“string”声明。在右侧,我们调用一种方法,因此“字符串”更明智。

string s = String.ToUpper() ;

#13

Lower case string is an alias for System.String.They are the same in C#.

小写字符串是System.String的别名。它们在C#中是相同的。

There's a debate over whether you should use the System types (System.Int32, System.String, etc.) types or the C# aliases (int, string, etc). I personally believe you should use the C# aliases, but that's just my personal preference.

关于是否应该使用系统类型(System.Int32,System.String等)类型或C#别名(int,string等)存在争议。我个人认为你应该使用C#别名,但这只是我个人的偏好。

#14

string is just an alias for System.String. The compiler will treat them identically.

string只是System.String的别名。编译器会以相同的方式处理它们。

The only practical difference is the syntax highlighting as you mention, and that you have to write using System if you use String.

唯一的实际区别是你提到的语法高亮,如果使用String,你必须使用System编写。

#15

Both are same. But from coding guidelines perspective it's better to use string instead of String. This is what generally developers use. e.g. instead of using Int32 we use int as int is alias to Int32

两者都是一样的。但从编码指南的角度来看,最好使用string而不是String。这是开发人员通常使用的。例如而不是使用Int32我们使用int作为int是Int32的别名

FYI“The keyword string is simply an alias for the predefined class System.String.” - C# Language Specification 4.2.3http://msdn2.microsoft.com/En-US/library/aa691153.aspx

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

#16

As the others are saying, they're the same. StyleCop rules, by default, will enforce you to use string as a C# code style best practice, except when referencing System.String static functions, such as String.Format, String.Join, String.Concat, etc...

正如其他人所说,他们是一样的。默认情况下,StyleCop规则将强制您使用字符串作为C#代码样式的最佳实践,除非引用System.String静态函数,例如String.Format,String.Join,String.Concat等...

#17

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

6年零5个月后的新答案(拖延)。

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.

虽然string是一个保留的C#关键字,它始终具有固定含义,但String只是一个可以引用任何内容的普通标识符。根据当前类型的成员,当前命名空间和应用的using指令及其位置,String可以是与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):

首先,当String是当前类型(或局部变量)的值时:

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).

以上将无法编译,因为IEnumerable <>没有名为Format的非静态成员,并且不应用任何扩展方法。在上面的例子中,仍然可以在其他上下文中使用String,其中类型是语法上唯一的可能性。例如String local =“Hi mum!”;可以没问题(取决于命名空间和使用指令)。

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

更糟糕的是:说String.Concat(someSequence)很可能(取决于使用)转到Linq扩展方法Enumerable.Concat。它不会转到静态方法string.Concat。

---

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

其次,当String是另一种类型时,嵌套在当前类型中:

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.

Example方法中的任何一个语句都不会编译。这里String总是一个钢琴弦,MyPiano.String。没有成员(静态或非静态)格式存在(或从其基类继承)。并且“Goodbye”的值不能转换成它。

#18

Using System types makes it easier to port between C# and VB.Net, if you are into that sort of thing.

使用系统类型可以更容易地在C#和VB.Net之间进行移植,如果你是这样的话。

#19

Against what seems to be common practice among other programmers, I prefer String over string, just to highlight the fact that String is a reference type, as Jon Skeet mentioned.

对于其他程序员似乎常见的做法,我更喜欢String over string,只是为了强调String是一个引用类型,正如Jon Skeet所提到的那样。

#20

string is an alias (or shorthand) of System.String. That means, by typing string we meant System.String. You can read more in think link: 'string' is an alias/shorthand of System.String.

string是System.String的别名(或简写)。这意味着,通过键入字符串我们的意思是System.String。您可以在思考链接中阅读更多内容:'string'是System.String的别名/简写。

#21

String (System.String) is a class in the base class library. string (lower case) is a reserved work in C# that is an alias for System.String. Int32 vs int is a similar situation as is Boolean vs. bool. These C# language specific keywords enable you to declare primitives in a style similar to C.

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

#22

I'd just like to add this to lfousts answer, from Ritchers book:

我想将此添加到来自Ritchers书中的lfousts答案中:

The C# language specification states, “As a matter of style, use of the keyword is favored over use of the complete system type name.” I disagree with the language specification; I prefer to use the FCL type names and completely avoid the primitive type names. In fact, I wish that compilers didn’t even offer the primitive type names and forced developers to use the FCL type names instead. Here are my reasons:

C#语言规范指出,“作为一种风格问题,使用关键字比使用完整的系统类型名称更受青睐。”我不同意语言规范;我更喜欢使用FCL类型名称并完全避免基本类型名称。实际上,我希望编译器甚至不提供原始类型名称,并强迫开发人员使用FCL类型名称。这是我的理由:

• I’ve seen a number of developers confused, not knowing whether to use string or String in their code. Because in C# string (a keyword) maps exactly to System.String (an FCL type), there is no difference and either can be used. Similarly, I’ve heard some developers say that int represents a 32-bit integer when the application is running on a 32-bit OS and that it represents a 64-bit integer when the application is running on a 64-bit OS. This statement is absolutely false: in C#, an int always maps to System.Int32, and therefore it represents a 32-bit integer regardless of the OS the code is running on. If programmers would use Int32 in their code, then this potential confusion is also eliminated.

  我看到许多开发人员感到困惑,不知道是否在他们的代码中使用字符串或字符串。因为在C#string(一个关键字)中精确映射到System.String(一种FCL类型),所以没有区别,任何一种都可以使用。类似地,我听说有些开发人员说当应用程序在32位操作系统上运行时,int表示32位整数,当应用程序在64位操作系统上运行时,它表示64位整数。这句话绝对是错误的:在C#中,int总是映射到System.Int32,因此它表示一个32位整数,而不管代码运行的操作系统如何。如果程序员在他们的代码中使用Int32,那么这种潜在的混淆也会被消除。

• In C#, long maps to System.Int64, but in a different programming language, long could map to an Int16 or Int32. In fact, C++/CLI does treat long as an Int32. Someone reading source code in one language could easily misinterpret the code’s intention if he or she were used to programming in a different programming language. In fact, most languages won’t even treat long as a keyword and won’t compile code that uses it.

  在C#中,长映射到System.Int64,但是在不同的编程语言中,long可以映射到Int16或Int32。实际上,C ++ / CLI确实将long视为Int32。如果某人使用一种语言阅读源代码,如果他或她习惯于使用不同的编程语言进行编程,则很容易误解代码的意图。事实上,大多数语言甚至不会将long视为关键字,也不会编译使用它的代码。

• The FCL has many methods that have type names as part of their method names. For example, the BinaryReader type offers methods such as ReadBoolean, ReadInt32, ReadSingle, and so on, and the System.Convert type offers methods such as ToBoolean, ToInt32, ToSingle, and so on. Although it’s legal to write the following code, the line with float feels very unnatural to me, and it’s not obvious that the line is correct:

  FCL有许多方法,它们将类型名称作为其方法名称的一部分。例如,BinaryReader类型提供诸如ReadBoolean,ReadInt32,ReadSingle等方法,而System.Convert类型提供诸如ToBoolean,ToInt32,ToSingle等方法。虽然编写下面的代码是合法的,但浮点线对我来说感觉非常不自然,并且线条不正确并不明显:

  BinaryReader br = new BinaryReader(...);float val = br.ReadSingle(); // OK, but feels unnaturalSingle val = br.ReadSingle(); // OK and feels good

• Many programmers that use C# exclusively tend to forget that other programming languages can be used against the CLR, and because of this, C#-isms creep into the class library code. For example, Microsoft’s FCL is almost exclusively written in C# and developers on the FCL team have now introduced methods into the library such as Array’s GetLongLength, which returns an Int64 value that is a long in C# but not in other languages (like C++/CLI). Another example is System.Linq.Enumerable’s LongCount method.

  许多使用C#的程序员都倾向于忘记可以使用其他编程语言来对抗CLR,因此,C#-isms会进入类库代码。例如,Microsoft的FCL几乎全部用C#编写,FCL团队的开发人员现在已经在库中引入了一些方法,例如Array的GetLongLength,它返回一个在C#中很长的Int64值,但在其他语言中却没有(比如C ++ / CLI) )。另一个例子是System.Linq.Enumerable的LongCount方法。

I didn't get his opinion before I read the complete paragraph.

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

#23

String is not a keyword and it can be used as Identifier whereas string is a keyword and cannot be used as Identifier. And in function point of view both are same.

String不是关键字,可以用作标识符,而string是关键字,不能用作标识符。并且在功能上看两者都是一样的。

#24

Coming late to the party: I use the CLR types 100% of the time (well, except if forced to use the C# type, but I don't remember when the last time that was).

聚会迟到:我100%使用CLR类型(好吧,除非*使用C#类型,但我不记得最后一次是什么时候)。

I originally started doing this years ago, as per the CLR books by Ritchie. It made sense to me that all CLR languages ultimately have to be able to support the set of CLR types, so using the CLR types yourself provided clearer, and possibly more "reusable" code.

根据Ritchie的CLR书籍,我最初几年前开始做这件事。我认为所有CLR语言最终都必须能够支持CLR类型集,因此使用CLR类型本身提供了更清晰,可能更“可重用”的代码。

Now that I've been doing it for years, it's a habit and I like the coloration that VS shows for the CLR types.

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

The only real downer is that auto-complete uses the C# type, so I end up re-typing automatically generated types to specify the CLR type instead.

唯一真正的下载是自动完成使用C#类型,所以我最终重新键入自动生成的类型来指定CLR类型。

Also, now, when I see "int" or "string", it just looks really wrong to me, like I'm looking at 1970's C code.

而且,现在,当我看到“int”或“string”时,我看起来真的很不对劲,就像我在看1970年代的C代码一样。

#25

It's a matter of convention, really. string just looks more like C/C++ style. 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.

真的,这是一个惯例问题。字符串看起来更像是C / C ++风格。一般惯例是使用您选择的语言提供的任何快捷方式(Int32的int / Int)。这也适用于“对象”和小数。

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.

从理论上讲,这有助于将代码移植到未来的64位标准中,其中“int”可能意味着Int64,但这不是重点,我希望任何升级向导都能更改Int32的任何int引用,只是为了安全起见。

#26

There is no difference.

没有区别。

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

C#关键字字符串映射到.NET类型System.String - 它是一个保持语言命名约定的别名。

Similarly, int maps to System.Int32.

同样,int映射到System.Int32。

#27

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

Daniel Solis的书中引用了这个问题。

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.

所有预定义类型都直接映射到底层.NET类型。 C#类型名称(字符串)只是.NET类型(String或System.String)的别名,因此使用.NET名称在语法上可以很好地工作,尽管不鼓励这样做。在C#程序中,您应该使用C#名称而不是.NET名称。

#28

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

string是关键字,您不能使用string作为标识符。

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

String不是关键字,您可以将其用作标识符:

Example

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.

除关键字问题外,关键字字符串是System.String的别名,两者完全等效。

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

#29

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

是的,他们之间没有区别,就像布尔和布尔一样。

#30

There is no difference between the two - string, however, appears to be the preferred option when considering other developers' source code.

两者之间没有区别 - 但是,在考虑其他开发人员的源代码时,它似乎是首选选项。