views:

16737

answers:

9

In C# the string keyword (highlighted in Visual Studio as a data type) is just a shortcut to the String class right?

In that case, it would be the same to use either while coding from the semantic point of view. However, is it the same from the performance point of view? I mean, when the mapping is performed: during compilation (I guess so), during compilation or during JIT compilation in execution?

Or maybe this is all wrong: string and String are not the same thing in C# so there are some situations where they cannot be interchanged

+14  A: 

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

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

TheSoftwareJedi
Jeffrey Richter recommends using the CLR type in all cases (CLR via C#) to avoid exactly the kind of confusion that is taking place here.
Josh
Clearly, whether you use S or s it will have caused this questions, so down-vote Richter. ;)
Brad Wilson
Richter meant that string shouldn't have been an option - Microsoft shouldn't have it in the language. You can't down-vote Richter - he's a legend! :)
Joe R
Richter is certainly a legend, and CLR via C# is wonderful - but that doesn't mean his opinions should be seen as ultimate truth :)(For an example, see http://msmvps.com/blogs/jon_skeet/archive/2008/10/08/why-boxing-doesn-t-keep-me-awake-at-nights.aspx)
Jon Skeet
Fair point Jon, but I just happen to agree with Richter on this point about String. And yes, I totally agree - CLR via C# is wonderful!
Joe R
I agree that it *might* have been better to not have the aliases at all. But given that we have them, I think it's fine to use them (but not in method names etc.)
Jon Skeet
+4  A: 

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

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

Hallgrim
You don't need to prefix System to use String.
Joe R
You do have to include a `using System` when using `String`, otherwise you get the following error: `The type or namespace name 'String' could not be found (are you missing a using directive or an assembly reference?)`
Ronald
+102  A: 

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-know by C# programmers.

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

artur02
+3  A: 

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

Pradeep Kumar Mishra
+99  A: 

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:

  • 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

Apart from string, 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.

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

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 {} // Invalid
public enum Bar : uint   {} // Valid

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.

Jon Skeet
The inheritance situation with enum is interesting. Can you point to documentation onto why alias must be used for enumerations? Or is this a known bug?
JaredPar
It's in section 14.1 of the spec (I can't quote here easily as it's too long). It doesn't explicitly say that you've got to use the alias, but the aliases are *sort of* treated as their own types. It's all a bit weird.
Jon Skeet
"the aliases are all to value types" is said twice about different sets of aliases. Can't be true both times %)
Yacoder
OMG! Jon Skeet answer... MUST ... CLICK ... UP ARROW!!!
PiPeep
+1  A: 

This question was essentially covered here and here already.

itsmatt
In this case the question was aimed most at performance/compilation considerations. I think those questions you mentioned were more general.
Toto
Sure, I got the gist of your question. Just trying to tie similar questions together because there were answers given in both of those which one could argue answer your question here. SO still needs some work to better 'tie' these questions together so I provided the links. No worries.
itsmatt
+6  A: 

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

TraumaPony
A: 

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

Lloyd Cotten
+1  A: 

I just wrote a short article on this topic, check it out on this link.