Qual é a diferença entre String e string em c#?




java string ou string (24)

Exemplo ( observe o caso ):

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

Quais são as diretrizes para o uso de cada um? E quais são as diferenças ?


Apenas por uma questão de perfeição, aqui está um despejo de informações relacionadas ...

Como outros já observaram, string é um alias para System.String . Eles compilam para o mesmo código, portanto, em tempo de execução, não há diferença alguma. Este é apenas um dos aliases em C #. A lista completa é:

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

Além da string e do object , os aliases são todos para tipos de valor. decimal é um tipo de valor, mas não um tipo primitivo no CLR. O único tipo primitivo que não possui um alias é System.IntPtr .

Na especificação, os alias de tipo de valor são conhecidos como "tipos simples". Literais podem ser usados ​​para valores constantes de todo tipo simples; nenhum outro tipo de valor tem formulários literais disponíveis. (Compare isso com VB, que permite literais DateTime , e tem um alias para isso também.)

Há uma circunstância na qual você deve usar os aliases: quando especificar explicitamente o tipo subjacente de um enum. Por exemplo:

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

Isso é apenas uma questão da maneira como a especificação define declarações de enum - a parte depois do cólon tem que ser a produção de tipo integral , que é um token de sbyte , byte , short , ushort , int , uint , long , ulong , char . .. ao contrário de um tipo de produção, usado por declarações de variáveis, por exemplo. Não indica outra diferença.

Finalmente, quando se trata de qual usar: pessoalmente eu uso os aliases em todos os lugares para a implementação, mas o tipo CLR para qualquer API. Realmente não importa muito o que você usa em termos de implementação - a consistência entre sua equipe é boa, mas ninguém mais vai se importar. Por outro lado, é realmente importante que, se você se referir a um tipo em uma API, faça isso de maneira neutra em relação à linguagem. Um método chamado ReadInt32 não é ambíguo, enquanto um método chamado ReadInt requer interpretação. O chamador pode estar usando uma linguagem que define um alias int para Int16 , por exemplo. Os designers do framework .NET seguiram esse padrão, sendo bons exemplos nas BitConverter , BinaryReader e Convert .


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.


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

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.

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.

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.

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


String significa System.String e é um tipo do .NET Framework. string é um alias na linguagem C # para System.String . Ambos são compilados em System.String em IL (Intermediate Language), então não há diferença. Escolha o que você gosta e use isso. Se você codificar em c #, eu prefiro string como é um alias do tipo c # e bem conhecido por programadores c #.

Eu posso dizer o mesmo sobre ( int , System.Int32 ) etc.


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.

Similarly, int maps to System.Int32 .


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.

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.


Há uma diferença - você não pode usar String sem using System; antecipadamente.


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


C # é uma linguagem que é usada em conjunto com o CLR.

string é um tipo em C #.

System.String é um tipo no CLR.

Quando você usa c # juntamente com a string CLR será mapeada para System.String .

Teoricamente, você poderia implementar um compilador C # que gerasse o bytecode Java. Uma implementação sensata desse compilador provavelmente mapearia string para java.lang.String para interoperar com a biblioteca de tempo de execução Java.


A melhor resposta que eu já ouvi sobre o uso dos aliases de tipos fornecidos em C # vem de Jeffrey Richter em seu livro CLR Via C # . Aqui estão suas 3 razões:

  • Eu vi um número de desenvolvedores confusos, sem saber se deveria usar string ou String em seu código. Como em C # a string (uma palavra-chave) mapeia exatamente para System.String (um tipo FCL), não há diferença e qualquer um deles pode ser usado.
  • Em C #, mapas longos para System.Int64 , mas em uma linguagem de programação diferente, tempo poderia mapear para um Int16 ou Int32 . Na verdade, o C ++ / CLI trata de fato como um Int32 . Alguém lendo código-fonte em um idioma poderia facilmente interpretar mal a intenção do código se ele ou ela estivesse acostumado a programar em uma linguagem de programação diferente. Na verdade, a maioria das linguagens nem sequer tratará como uma palavra-chave e não compilará o código que a utiliza.
  • O FCL possui muitos métodos que possuem nomes de tipos como parte de seus nomes de métodos. Por exemplo, o tipo BinaryReader oferece métodos como ReadBoolean , ReadInt32 , ReadSingle e assim por diante, e o tipo System.Convert oferece métodos como ToBoolean , ToInt32 , ToSingle e assim por diante. Embora seja legal escrever o código a seguir, a linha com float parece muito pouco natural para mim, e não é óbvio que a linha esteja correta:
BinaryReader br = new BinaryReader(...);
float val  = br.ReadSingle(); // OK, but feels unnatural
Single val = br.ReadSingle(); // OK and feels good

Então você tem isso. Eu acho que esses são todos bons pontos. Eu, no entanto, não me encontro usando o conselho de Jeffrey em meu próprio código. Talvez eu esteja muito preso no meu mundo C #, mas acabo tentando fazer o meu código parecer o código do framework.


String ( System.String ) é uma classe na biblioteca de classes base. string (caixa baixa) é um trabalho reservado em C # que é um alias para System.String. Int32 vs int é uma situação semelhante à Boolean vs. bool . Essas palavras-chave específicas da linguagem C # permitem declarar primitivos em um estilo semelhante a C.


System.String é a classe de string do .NET - em C # string é um alias para System.String - portanto, em uso, eles são os mesmos.

Quanto às diretrizes, eu não ficaria muito atolado e apenas usaria o que você sentir - há coisas mais importantes na vida e o código será o mesmo.

Se você se encontrar construindo sistemas onde é necessário especificar o tamanho dos números inteiros que você está usando e então usar Int16 , Int32 , UInt16 , UInt32 etc. então pode parecer mais natural usar String - e quando se mover entre diferentes .net pode tornar as coisas mais compreensíveis - caso contrário eu usaria string e int.


Foi coberto acima; no entanto, você não pode usar string em reflexão; você deve usar String .


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:

Exemplo

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)

string é apenas um alias para System.String . O compilador irá tratá-los de forma idêntica.

A única diferença prática é o destaque da sintaxe, como você mencionou, e que você tem que escrever using System se você usar String .


Usando tipos de sistema torna mais fácil a porta entre C # e VB.Net, se você está nesse tipo de coisa.


Eu gostaria de acrescentar isso à resposta do livro Ritchers:

A especificação da linguagem C # declara: “Por uma questão de estilo, o uso da palavra-chave é favorecido sobre o uso do nome completo do tipo de sistema.” Eu discordo da especificação da linguagem; Eu prefiro usar os nomes de tipo FCL e evitar completamente os nomes de tipos primitivos. Na verdade, eu gostaria que os compiladores nem oferecessem nomes de tipos primitivos e forçassem os desenvolvedores a usar os nomes de tipos FCL. Aqui estão minhas razões:

  • Eu vi um número de desenvolvedores confusos, sem saber se deveria usar string ou String em seu código. Como em C # string (uma palavra-chave) mapeia exatamente para System.String (um tipo FCL), não há diferença e pode ser usado. Da mesma forma, ouvi alguns desenvolvedores dizerem que int representa um inteiro de 32 bits quando o aplicativo está sendo executado em um sistema operacional de 32 bits e que representa um inteiro de 64 bits quando o aplicativo está sendo executado em um sistema operacional de 64 bits. Essa instrução é absolutamente falsa: em C #, um int sempre é mapeado para System.Int32 e, portanto, representa um inteiro de 32 bits, independentemente do SO em que o código está sendo executado. If programmers would use Int32 in their code, then this potential confusion is also eliminated.

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

  • 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:

    BinaryReader br = new BinaryReader(...);
    float val = br.ReadSingle(); // OK, but feels unnatural
    Single 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.

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


string e String são idênticos de todas as formas (exceto o "S" maiúsculo). Não há implicações de desempenho de qualquer maneira.

A string minúscula é preferida na maioria dos projetos devido ao destaque da sintaxe


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


Este vídeo do YouTube demonstra praticamente como eles diferem.

Mas agora para uma resposta textual longa.

Quando falamos em .NET há duas coisas diferentes: uma existe o .NET framework e a outra, linguagens ( C# , VB.NET etc) que usam essa estrutura.

" System.String " aka "String" (capital "S") é um tipo de dados de estrutura .NET , enquanto "string" é um tipo de dados C# .

Em suma, "String" é um alias (a mesma coisa chamada com nomes diferentes) de "string". Então, tecnicamente, ambas as instruções de código abaixo darão a mesma saída.

String s = "I am String";

ou

string s = "I am String";

Da mesma forma, existem aliases para outro tipo de dados c #, como mostrado abaixo:

objeto: System.Object , string: System.String , bool: System.Boolean , byte: System.Byte , sbyte: System.SByte , abreviado: System.Int16 e assim por diante

Agora, a pergunta de milhões de dólares do ponto de vista do programador Então, quando usar "String" e "string"?

A primeira coisa a evitar confusão é usar um deles consistentemente. Mas, do ponto de vista de melhores práticas, quando você faz declaração de variáveis, é bom usar "string" (small "s") e quando você está usando como um nome de classe, então "String" (maiúscula "S") é o preferido.

No código abaixo, o lado esquerdo é uma declaração de variável e é declarado usando "string". No lado direito, estamos chamando um método, então "String" é mais sensível.

string s = String.ToUpper() ;

Eu prefiro os tipos .NET capitalizados (em vez dos aliases) por razões de formatação. Os tipos .NET são coloridos da mesma forma que outros tipos de objetos (afinal, os tipos de valor são objetos apropriados).

Palavras-chave condicionais e de controle (como if , switch e return ) são minúsculas e coloridas em azul escuro (por padrão). E eu prefiro não ter o desacordo em uso e formato.

Considerar:

String someString; 
string anotherString; 

string é uma palavra reservada, mas String é apenas um nome de classe. Isso significa que a string não pode ser usada como um nome de variável por si só.

Se por algum motivo você quisesse uma variável chamada string , você veria apenas a primeira dessas compilações:

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

Se você realmente quer um nome de variável chamado string, você pode usar @ como um prefixo:

StringBuilder @string = new StringBuilder();

Outra diferença importante: o os destaca de maneira diferente.


Como os outros estão dizendo, eles são o mesmo. As regras StyleCop, por padrão, obrigarão você a usar string como uma prática recomendada em estilo de código C #, exceto quando fizer referência a funções estáticas System.String , como String.Format , String.Join , String.Concat , etc ...






alias