¿Es Int32.ToString () específico de la cultura?

Estoy ejecutando una versión beta de ReSharper, y me da advertencias para el siguiente código:

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

La advertencia está en la llamada id.ToString() , y me está diciendo “Especifique una cultura en la conversión de cadenas explícitamente”. Entiendo la advertencia, y sé cómo solucionarlo, simplemente cambie el código a id.ToString(CultureInfo.InvariantCulture) mucho más difícil de manejar.

Pero mi pregunta es: ¿es eso necesario? Quiero decir, obviamente es importante especificar la cultura cuando utilizas tipos como DateTime (diferentes culturas tienen diferentes formatos de fecha) y Double (se usan diferentes caracteres para el punto decimal). Pero Int32.ToString() , al menos en las culturas en-US e invariante, no agrega ningún formato en absoluto. Sin comas, sin puntos decimales, sin signos de dólar, nada. Entonces, ¿qué habría para variar según la cultura?

¿Existen algunas culturas que realmente agreguen algún tipo de formato cuando se llama al parámetro Int32.ToString() ? ¿O es esto un error en la versión beta de ReSharper, y esta advertencia realmente no es aplicable a Int32 (en cuyo caso presentaré un informe de error de ReSharper)?

El sistema operativo permite cambiar el signo negativo para los números.

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

Entonces, la cultura actual podría haber anulado el signo negativo. En este caso, debe respetar la configuración regional, esta es la razón de la advertencia. También puede cambiar el signo negativo programáticamente:

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

Como se probó en una muestra aleatoria de ints, las 352 culturas instaladas con Windows ( CultureTypes.InstalledWin32Cultures ) arrojan resultados idénticos.

Daniel tiene razón al señalar que una cultura personalizada podría usar un prefijo diferente para los números negativos, pero dudo que alguien haya usado alguna vez esta función, salvo por accidente.

Creo que los desarrolladores de .NET lo hicieron para ser coherentes con Float y otros tipos. ¿Qué más esperaban?

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

Sí. Depende de la cultura actual. Desde los documentos de MSDN :

El valor de retorno se formatea con el especificador de formato numérico general (“G”) y el objeto NumberFormatInfo para la cultura actual .

énfasis mío

Lo más probable es que Resharper quiera que sea explícito con respecto a la cultura que tiene la intención de usar. Ya que omitirlo depende del comportamiento que puede cambiar cuando se ejecuta en diferentes máquinas.

Es raro; Hubiera esperado 50.ToString (CultureInfo.CreateSpecificCulture (“ar-AE”)) para devolver “50”, pero no es así.

Acabo de ver esto, y el problema parece ser que NumberFormatInfo.DigitSubstitution no se implementó realmente

La propiedad DigitSubstitution está reservada para uso futuro. Actualmente, no se usa en operaciones de análisis ni de formateo para el objeto NumberFormatInfo actual.

Entonces, aunque hay una enumeración System.Globalization.DigitShapes, en realidad no se implementa en el bit NumberFormatInfo de IFormatProvider.

Hubiera dicho que no, pero al verificar MSDN Int32.ToString () hay esto:

El valor de retorno se formatea con el especificador de formato numérico general (“G”) y el objeto NumberFormatInfo para la cultura actual.

Entonces hay una sorpresa.

La pregunta debería ser ¿por qué el Resharper actual no sugiere esto?

Porque los enteros pueden ser tan altos como 2,147,483,647.

En algunos países , usarían decimales o un espacio en lugar de las comas.