Int32.ToString () é específico da cultura?

Estou executando uma versão beta do ReSharper e está me dando avisos para o seguinte código:

int id; // ... DoSomethingWith(id.ToString()); 

O aviso está na chamada id.ToString() e está me dizendo “Especifique uma cultura na conversão de string explicitamente”. Eu entendo o aviso, e sei como consertá-lo – apenas mude o código para o id.ToString(CultureInfo.InvariantCulture) muito mais difícil de id.ToString(CultureInfo.InvariantCulture) .

Mas a minha pergunta é: isso é necessário? Quero dizer, obviamente, é importante especificar a cultura quando você estiver usando tipos como DateTime (diferentes culturas têm diferentes formatos de data) e Double (caracteres diferentes usados ​​para o ponto decimal). Mas Int32.ToString() , pelo menos nas culturas en-US e invariantes, não adiciona formatação alguma. Sem vírgulas, sem pontos decimais, sem sinais de dólar, nada. Então, o que haveria para variar de acordo com a cultura?

Existem algumas culturas que realmente adicionam algum tipo de formatação quando você chama o Int32.ToString() parâmetros? Ou isso é um bug no beta do ReSharper, e este aviso realmente não é aplicável ao Int32 (nesse caso eu vou registrar um relatório de bug do ReSharper)?

O sistema operacional permite alterar o sinal negativo para números.

 Control panel -> Language and regional settings -> Additional settings -> Negative sign 

Então, a cultura atual poderia ter substituído o sinal negativo. Neste caso, você precisa respeitar as configurações regionais, esta é a razão do aviso. Você também pode alterar o sinal negativo programaticamente:

  CultureInfo culture = Thread.CurrentThread.CurrentCulture; // Make a writable clone culture = (CultureInfo) culture.Clone(); culture.NumberFormat.NegativeSign = "!"; 

Como testado em uma amostra aleatória de ints, todas as 352 culturas instaladas com o Windows ( CultureTypes.InstalledWin32Cultures ) fornecem resultados idênticos.

Daniel está certo ao observar que uma cultura personalizada poderia usar um prefixo diferente para números negativos, mas duvido que alguém já tenha usado esse recurso, salvo por acidente.

Eu acho que os desenvolvedores .NET fizeram isso para ser consistente com float e outros tipos. O que mais eles esperavam?

 > int.MaxValue.ToString(CultureInfo.AncientRome) MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM.... 

Sim. Depende da cultura atual. Nos documentos do MSDN :

O valor de retorno é formatado com o especificador de formato numérico geral (“G”) e o object NumberFormatInfo para a cultura atual .

ênfase minha

Resharper provavelmente quer que você seja explícito sobre a cultura que você pretende usar. Já que omitir, ele depende de um comportamento que pode mudar quando executado em máquinas diferentes.

É estranho; Eu teria esperado 50.ToString (CultureInfo.CreateSpecificCulture (“ar-AE”)) para retornar “٥٠”, mas isso não acontece.

Acabei de ver isso, e o problema parece ser que NumberFormatInfo.DigitSubstitution não está realmente implementado

A propriedade DigitSubstitution está reservada para uso futuro. Atualmente, ele não é usado em operações de análise ou formatação para o object NumberFormatInfo atual.

Portanto, embora haja uma enumeração System.Globalization.DigitShapes, ele não é realmente implementado no bit NumberFormatInfo de IFormatProvider.

Eu teria dito não, mas ao verificar o MSDN Int32.ToString (), tem isto:

O valor de retorno é formatado com o especificador de formato numérico geral (“G”) e o object NumberFormatInfo para a cultura atual.

Então há uma surpresa.

A pergunta deve ser por que o Resharper atual não sugere isso?

Porque inteiros podem ser tão altos quanto 2.147.483.647.

Em alguns países , eles usariam decimais ou um espaço no lugar das vírgulas.