The string type represents a sequence of zero or more Unicode characters.
string is an alias for String in the .NET Framework.
http://msdn2.microsoft.com/en-us/library/362314fe(VS.80).aspx
> As a mainly C/C++ and Java developer I was quite surprised when I realized
> that C# compiler takes both "string" and "String" types. C# is case
> sensitive so I'm a bit puzzled by that. Could someone please explain
> that or point me to on-line docs?
>
> thx
> As a mainly C/C++ and Java developer I was quite surprised when I realized
> that C# compiler takes both "string" and "String" types. C# is case
> sensitive so I'm a bit puzzled by that. Could someone please explain that
> or point me to on-line docs?
>
> thx
C# has defined its own keywords for the basic types. They all compile to
the type in the BCL that corresponds.
Other such keywords are:
int -> Int32
short -> Int16
ushort -> UInt16
bool -> Boolean
float -> Single
etc.
Note that string and String is 100% identical as string is compiled as
String.
The only place that I know of that one of them can be used and not the
other is when specifying the size of an enum like inheritance:
public enum SomeEnum : int
in this case it is apparently not legal to use Int32 instead of int, for
some odd reason.

Signature
Lasse Vågsæther Karlsen
mailto:lasse@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3
> As a mainly C/C++ and Java developer I was quite surprised when I realized
> that C# compiler takes both "string" and "String" types. C# is case
> sensitive so I'm a bit puzzled by that. Could someone please explain that
> or point me to on-line docs?
Actually C# doesn't understand a String type. It does understand a
System.String type, and you can refer to that as just String, if you
happen to have a
using System;
statement at the top of your file (and it is some time since I saw a
C# file that /didn't/ have such a statement).
C# does understand the 'string' type, which it internally converts to
System.String32 (much as it converts 'short' to System.Int16).
My personal preference is to always use the C# names, unless I want to
emphasize the exact length of an integer (in which case, I'll use
System.Int64 or whatever).
Arne Vajhøj - 12 Mar 2008 02:35 GMT
> Actually C# doesn't understand a String type. It does understand a
> System.String type, and you can refer to that as just String, if you
> happen to have a
> using System;
> statement at the top of your file (and it is some time since I saw a
> C# file that /didn't/ have such a statement).
I think most C# programmers will expect it to be there.
> C# does understand the 'string' type, which it internally converts to
> System.String32 (much as it converts 'short' to System.Int16).
s/32//w
> My personal preference is to always use the C# names, unless I want to
> emphasize the exact length of an integer (in which case, I'll use
> System.Int64 or whatever).
Me too.
But I suspect that it is because I also code in C/C++/Java.
Arne
Martin Bonner - 12 Mar 2008 15:20 GMT
> > Actually C# doesn't understand a String type. It does understand a
> > System.String type, and you can refer to that as just String, if you
[quoted text clipped - 9 lines]
>
> s/32//w
D'oh! :-)
> > My personal preference is to always use the C# names, unless I want to
> > emphasize the exact length of an integer (in which case, I'll use
[quoted text clipped - 3 lines]
>
> But I suspect that it is because I also code in C/C++/Java.
Perhaps, but I think I would recommend it as a good convention even
for a pure C# development.
Marc Gravell - 12 Mar 2008 15:27 GMT
> My personal preference is to always use the C# names, unless I want to
> emphasize the exact length of an integer (in which case, I'll use
> System.Int64 or whatever).
This is also good practice if you are exposing the name as part of a method
(or other API etc), since the caller could be any language. Examples:
IDataReader.GetInt32(), Convert.ToInt64()
Marc