todouble - parse bool to int c#

¿Por qué existe Convert.ToInt32(Int32)?

Question

Hay una sobrecarga de Convert.ToInt32 que toma Int32 como parámetro. Pero incluso la documentación dice que, básicamente, no pasa nada y el método devuelve su entrada.

La pregunta es ¿por qué tenemos tal sobrecarga? ¿Hay algún propósito de ello? ¿Puede alguien darme un ejemplo del uso de este método?

Mis pensamientos : Creo que podemos tenerlo porque hay una sobrecarga que toma Objeto. Y así queremos eliminar el boxeo y así sucesivamente. Pero no estoy seguro.

Answer 1

Aquí está la descripción del método:

 //
// Summary:
// Returns the specified 32-bit signed integer; no actual conversion is performed.
//
// Parameters:
// value:
// The 32-bit signed integer to return.
//
// Returns:
// value is returned unchanged.

Lo único que se me ocurre es que es un acceso directo / paso si la entrada ya es un int . Es probable que sea mucho más eficiente que si se pasara un int a Convert.ToInt32(object) .

Answer 2

Common Language Runtime utiliza internamente la interfaz IConvertible. Como los tipos de base CLR son Boolean, SByte, Byte, Int16, UInt16, Int32, UInt32, Int64, UInt64, Single, Double, Decimal, DateTime, Char y String, hay una implementación para cada uno de ellos en la clase Convert.

Pero, por ejemplo, Convert.toBoolean (DateTime) siempre devuelve una excepción, por diseño.

Answer 3

Mis ideas:

• Para la generación de código : Especialmente en .NET 2.0, se generó una gran cantidad de código como, por ejemplo, conjuntos de datos escritos. Tener una sobrecarga como Convert.ToInt32(Int32) simplifica el generador de código pero no obstaculiza el rendimiento en tiempo de ejecución, ya que la llamada probablemente se retira inmediatamente.
• Por coherencia : hay una interfaz IConvertible en .NET desde 2.0 o quizás incluso desde 1.0 que utiliza la clase Convert. Esta interfaz exige métodos como ToInt32, etc.

Generación de código (más detalles): el método habitual para generar código en .NET 2.0 veces fue System.CodeDOM, ya que proporciona medios para reutilizar el mismo generador de código para múltiples idiomas, principalmente VB.NET y C #. En CodeDOM, no necesita saber de qué tipo es una expresión dada para llamar a un método, simplemente puede crear un CodeMethodCallExpression dado en la expresión del objeto de destino y el nombre de los métodos. Por otro lado, muchos operadores de conversión tales como C # s como operador no son compatibles con CodeDOM.

Como consecuencia, a menudo es difícil saber el tipo de una expresión de código dada en CodeDOM. Esto tiene mucho sentido, ya que muchos métodos que puede involucrar una expresión también forman parte del código generado y, por lo tanto, se desconocen en el momento de la generación. Sin embargo, en algunos casos necesita una expresión particular convertida a un tipo dado, como System.Int32 . Puedo imaginar que esto sucedió realmente con los conjuntos de datos escritos, aunque no estoy 100% seguro. Debido a que Convert.ToInt32 existe, el generador no necesita saber si una expresión dada es de tipo System.Int32 o no. Cuando el compilador compila el código generado, todas las firmas de métodos están disponibles y el compilador puede darse cuenta de que el tipo de expresión es System.Int32 y llamar a la sobrecarga apropiada.

Por otro lado, el compilador JIT detectará que el método Convert.ToInt32 simplemente devolverá su argumento. Pero como el método no es virtual, el cuerpo de los métodos se puede insertar en el código de las personas que llaman en lugar de llamar a Convert.ToInt32 ya que la sobrecarga de llamar al método sería mucho mayor que la del método.

Answer 4

Podemos derivar una posible respuesta de los usos de ToInt32 (Int32) en las clases marco.

Ej. System.Activities.DurableInstancing.SerializationUtilities

public static byte[] CreateKeyBinaryBlob(List<CorrelationKey>correlationKeys)
{
[...]
Convert.ToInt32(correlationKey.BinaryData.Count)

y System.ComponentModel.Design.CollectionEditor

private void PaintArrow(Graphics g, Rectangle dropDownRect)
{
Point point = new Point(Convert.ToInt32(dropDownRect.Left + dropDownRect.Width / 2), Convert.ToInt32(dropDownRect.Top + dropDownRect.Height / 2));

En ambos casos, podemos ver que el tipo de propiedad o expresión es actualmente Int32, pero existe una expectativa razonable de que / quizás / ese tipo podría ser diferente en diferentes plataformas, arquitecturas de CPU, futuras versiones del marco, etc.

Así que mi respuesta propuesta es que existe como una especie de futura prueba del código fuente, para permitir que se compile sin modificaciones, incluso cuando algunas "entidades" clave (como las ventanas X y Y) cambian el tipo.

Answer 5

Sólo los diseñadores de API saben.

Si tuviera que adivinar, supongo que es por coherencia, por ejemplo, cuando está utilizando la reflexión para crear llamadas dinámicamente, es más fácil si puede suponer que cada Convert.ToX(Y) existe Para cualquier tipo primitivo X e Y