В чем разница между String и String в C#?

Просто для полноты картины, вот свалка соответствующей информации...

как уже отмечалось, 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.

в спецификации псевдонимы типов значений известны как"простые типы". Литералы можно использовать для постоянных значений каждого простого типа; никакие другие типы значений не имеют доступных литеральных форм. (Сравните это с VB, который позволяет DateTime литералы, и имеет псевдоним для него тоже.)

есть одно обстоятельство, при котором вы есть использовать псевдонимы: при явном указании базового типа перечисления. Для пример:

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

это просто вопрос того, как спецификация определяет объявления перечисления-часть после двоеточия должна быть Интеграл-типа производство, которое является одним из символов sbyte, byte, short, ushort, int, uint, long, ulong, char... в отличие от тип производства как объявления переменных например. Это не указывает на какую-либо другую разницу.

наконец, когда дело доходит до что использовать: лично я использую псевдонимы везде для реализации, но тип CLR для любых API. На самом деле не имеет большого значения, что вы используете с точки зрения реализации - согласованность среди вашей команды хороша, но никто другой не будет заботиться. С другой стороны, действительно важно, что если вы ссылаетесь на тип в API, вы делаете это нейтральным языком. Метод называется ReadInt32 является однозначным, тогда как метод называется ReadInt требует интерпретации. Звонивший может быть использование языка, который определяет int псевдоним Int16, например. Дизайнеры .NET framework следовали этому шаблону, хорошие примеры были в BitConverter, BinaryReader и Convert классы.

String расшифровывается как System.String и это тип .NET Framework. string псевдоним на языке C# для System.String. Оба они скомпилированы в System.String in IL (промежуточный язык), поэтому нет никакой разницы. Выберите то, что вам нравится, и используйте это. Если вы кодируете на C#, я бы предпочел string поскольку это псевдоним типа C# и хорошо известный программистам C#.

Я могу сказать то же самое о (int, System.Int32) etc..

лучший ответ, который я когда-либо слышал об использовании предоставленных псевдонимов типов в C#, исходит от Джеффри Рихтера в его книге CLR через C#. Вот его 3 причины:

• Я видел ряд застройщиков в замешательстве, не зная, следует ли использовать строка или строка в своем коде. Потому что в C# строка (ключевое слово) точно соответствует системе.Строка (тип FCL), нет никакой разницы, и либо может использоваться.
• В C#долго карты в Система.Int64, но на другом языке программирования,долго можно сопоставить с INT16 в или int32 значение. Фактически, C++ / CLI фактически обрабатывает long как int32 значение. Тот, кто читает исходный код на одном языке, может легко неверно истолковать намерение кода, если он или она привыкли программировать на другом языке программирования. На самом деле, большинство языков даже не лечат долго как ключевое слово и не будет компилировать код, который его использует.
• FCL имеет много методов, которые имеют имена типов как часть их имен методов. Например,BinaryReader type предлагает такие методы, как ReadBoolean, ReadInt32, ReadSingle и так далее, и

string - зарезервированное слово, но String - это просто имя класса. Это значит, что string не может использоваться как имя переменной само по себе.

если по какой-то причине вам нужна переменная строка, вы увидите только первый из них составляет:

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

если вы действительно хотите имя переменной с именем строка можно использовать @ в качестве префикса:

StringBuilder @string = new StringBuilder();

другое критическое отличие: переполнение стека выделяет их иначе.

есть одно отличие - вы не можете использовать String без using System; заранее.

Это было описано выше; однако, вы не можете использовать string в отражении; вы должны использовать String.

System.String - Это класс .NET string - в C# string псевдоним System.String - таким образом, в использовании они одинаковы.

Что касается руководящих принципов, я бы не слишком увяз и просто использовать то, что вы чувствуете, как - есть более важные вещи в жизни, и код будет таким же в любом случае.

если вы обнаружите, что строите системы, где необходимо указать размер целых чисел, которые вы используете, и поэтому склонны использовать Int16, Int32, UInt16, UInt32 etc. тогда это может выглядеть более естественно использовать String - и при перемещении между разными языками .net это может сделать вещи более понятными-в противном случае я бы использовал string и int.

Я предпочитаю заглавные .NET типы (а не псевдонимы) по причинам форматирование. The .NET типы окрашены так же, как и другие типы объектов (в конце концов, типы значений являются правильными объектами).

условные и контрольные ключевые слова (например,if, switch и return) строчные и цветные темно-синие (по умолчанию). И я бы предпочел не иметь разногласий в использовании и формат.

считаем:

String someString; 
string anotherString; 

string и String идентичны во всех отношениях (кроме верхнего регистра "S"). В любом случае нет никаких последствий для производительности.

строчные string предпочтителен в большинстве проектов из-за подсветки синтаксиса

C# - это язык, который используется вместе с CLR.

string тип в C#.

System.String является типом в CLR.

когда вы используете C# вместе с CLR string будет соответствовать System.String.

теоретически вы можете реализовать C#-компилятор, который сгенерировал байт-код Java. Разумная реализация этого компилятора, вероятно, map string к java.lang.String для взаимодействия с библиотекой времени выполнения Java.

Это YouTube видео демонстрирует практически, чем они отличаются.

но теперь для длинного текстового ответа.

когда мы говорим о .NET есть две разные вещи, одно есть .NET framework и другие существуют языки ( C# , VB.NET etc), которые используют эту структуру.

"System.String " a.к."строка" (заглавная "S") - это .NET тип данных framework в то время как" string " является C# сведения тип.

короче говоря, "String" - это псевдоним ( то же самое, что называется с разными именами)"string". Так что технически как ниже код даст тот же результат.

String s = "I am String";

или

string s = "I am String";

таким же образом существуют псевдонимы для другого типа данных c#, как показано ниже: -

string - Это просто псевдоним для System.String. Компилятор будет относиться к ним одинаково.

единственным практическим отличием является подсветка синтаксиса, как вы упомянули, и что вы должны написать using System Если вы используете String.

нижний регистр string псевдоним System.String. Они одинаковы в C#.

существует дискуссия о том, следует ли использовать системные типы (System.Int32, System.String, etc.) типы или C# aliases (int, string и т. д.). Я лично считаю, что вы должны использовать C# aliases, но это только мое личное предпочтение.

одинаковы. Но с точки зрения руководства по кодированию лучше использовать string вместо String. Это то, что обычно используют разработчики. например, вместо использования Int32 мы используем:int as int - это псевдоним Int32

к вашему сведению "Строка ключевого слова - это просто псевдоним для предопределенного класса System.String."- Спецификация Языка C# 4.2.3 http://msdn2.microsoft.com/En-US/library/aa691153.aspx

как говорят другие, они такие же. Правила StyleCop по умолчанию заставят вас использовать string как лучшая практика стиля кода C#, за исключением случаев ссылки System.String статические функции, такие как String.Format, String.Join, String.Concat, etc...

использование системных типов упрощает перенос между C# и VB.Net если ты в этом разбираешься.

против того, что кажется обычной практикой среди других программистов, я предпочитаю String над string, просто чтобы подчеркнуть тот факт, что String является ссылочным типом, как Джон Скит упоминается.

string - псевдоним (или стенография)System.String. Это означает, набрав string мы имели в виду System.String. Вы можете прочитать больше в think link:'string' - это псевдоним / стенография системы.Строка.

строка (System.String) - Это класс в библиотеке базовых классов. строка (нижний регистр) - это зарезервированная работа в C#, которая является псевдонимом для System.Строка. Int32 vs int-аналогичная ситуация, как Boolean vs. bool. Эти ключевые слова языка C# позволяют объявлять примитивы в стиле, подобном C.

String не является ключевым словом, и его можно использовать в качестве идентификатора, тогда как string - Это ключевое слово и не может использоваться в качестве идентификатора. И с функциональной точки зрения оба они одинаковы.

опоздание на вечеринку: я использую типы CLR в 100% случаев (ну, кроме если заставили использовать тип C#, но я не помню, когда в последний раз был).

Я изначально начал делать это много лет назад, согласно книгам CLR Ричи. Для меня имело смысл, что все языки CLR в конечном итоге должны быть в состоянии поддерживать набор типов CLR, поэтому использование типов CLR самостоятельно обеспечило более четкий и, возможно, более "многоразовый" код.

теперь, когда я делал это в течение многих лет, это привычка, и мне нравится окраска, которую VS показывает для типов CLR.

единственным реальным недостатком является то, что автозаполнение использует тип C#, поэтому я в конечном итоге повторно набираю автоматически сгенерированные типы, чтобы указать тип CLR.

кроме того, теперь, когда я вижу "int" или "string", это просто выглядит очень неправильно для меня, как будто я смотрю на код 1970-х годов.

Я просто хотел бы добавить это к ответу lfousts, из книги Ритчерса:

состояния спецификации языка C# , "Как вопрос стиля, использование ключевое слово предпочтительнее использования полное имя типа системы."Я не согласен со спецификацией языка; I предпочитайте использовать имена типов FCL и полностью избегайте примитивного типа имена. На самом деле, я хочу, чтобы компиляторы даже не предложил примитивный тип имена и заставили разработчиков использовать ГКЛ вместо этого введите имена. Вот мои причины:

Я не получил его мнение, прежде чем прочитать полный абзац.

это вопрос конвенции, на самом деле. string просто больше похоже на стиль C / C++. Общее соглашение заключается в использовании любых ярлыков, предоставленных выбранным вами языком (int / Int for Int32). Это относится к "объекту" и decimal Как хорошо.

теоретически это может помочь перенести код в какой-то будущий 64-битный стандарт, в котором "int" может означать Int64, но дело не в этом, и я ожидал бы, что любой мастер обновления изменит любой int ссылки Int32 в любом случае просто быть безопасным.

нет никакой разницы.

ключевое слово C#string карты .Сетка типа System.String - это псевдоним, который соответствует соглашениям об именах языка.

аналогично, int карты System.Int32.

новый ответ после 6 лет и 5 месяцев (прокрастинация).

пока string является зарезервированным ключевым словом C#, которое всегда имеет фиксированное значение,String - это просто обычный идентификатор что может относиться к чему угодно. В зависимости от членов текущего типа, текущего пространства имен и применяемого using директивы и их размещение, String может быть значением или типом, отличным от global::System.String.

я приведу два примера, где using директивы не поможет.

во-первых, когда String - это стоимостью текущего типа (или локальной переменной):

class MySequence<TElement>
{
  public IEnumerable<TElement> String { get; set; }

  void Example()
  {
    var test = String.Format("Hello {0}.", DateTime.Today.DayOfWeek);
  }
}

выше не будет компилироваться, потому что IEnumerable<> не имеет нестатического члена с именем Format, и никакие методы расширения не применяются. В приведенном выше случае все еще можно использовать String в других контекстах, где тип - единственная возможность синтаксически. Например String local = "Hi mum!"; может быть в порядке (в зависимости от пространства имен и using директивы).

Хуже: Говорю String.Concat(someSequence) скорее всего (в зависимости от usings) перейдите к методу расширения Linq Enumerable.Concat. Он не перейдет к статическому методу string.Concat.

во-вторых, когда String другое тип, вложенный внутри текущего типа:

class MyPiano
{
  protected class String
  {
  }

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

ни одно утверждение в Example метод компилирует. Вот!--3--> всегда фортепиано строка, MyPiano.String. Нет члена (static или нет) Format существует на нем (или наследуется от его базового класса). И значение "Goodbye" не может быть преобразован в него.

есть цитата по этому вопросу из книга Даниэля Солиса.

все предопределенные типы сопоставляются непосредственно с базовых .Чистых типов. Имена типов C# (string) - это просто псевдонимы для Типы .NET (String или System.String), поэтому использование имен .NET отлично работает синтаксически, хотя это обескураживает. В программе на C# следует использовать имена на C# вместо имен .NET.

строка - ключевое слово, и вы не можете использовать строку в качестве идентификатора.

строка не является ключевым словом, и вы можете использовать его в качестве идентификатора:

пример

string String = "I am a string";

ключевое слово string - это псевдоним для System.String помимо проблемы с ключевым словом, эти два точно аналог.

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

Да, это не разница между ними, как и bool и Boolean.

нет никакой разницы между двумя - string, однако, кажется предпочтительным вариантом при рассмотрении исходного кода других разработчиков.