为什么Convert.ToInt32(Int32)存在吗?

There is an overload of Convert.ToInt32 that takes Int32 as the parameter. But even the documentation says that basically nothing happens and the method returns its input.

转换的负荷过重。以Int32为参数。但是即使是文档也说基本上什么都没有发生，方法返回它的输入。

The question is why do we have such overload? Is there any purpose of it? Can anyone give me an example of using this method?

问题是为什么我们的负担如此沉重?有什么目的吗?谁能给我举一个使用这种方法的例子吗?

My thoughts: I think we may have it because there is an overload that takes Object. And thus we want to eliminate boxing and so on. But I'm not sure.

我的想法是:我认为我们可能拥有它，因为有一个超负荷的目标。因此我们想要消除拳击等等。但我不确定。

5 个解决方案

#1

My ideas:

我的想法:

For code generation: Especially in .NET 2.0, a lot of code as e.g. typed data sets were generated. Having an overload like Convert.ToInt32(Int32) simplifies the code generator but does not hamper runtime performance, since the call is probably JITed away immediately
对于代码生成:特别是在。net 2.0中，生成了很多代码，比如类型化数据集。拥有一个像Convert.ToInt32(Int32)这样的重载可以简化代码生成器，但不会影响运行时性能，因为调用可能会立即被调用
For consistency: There is an IConvertible interface in .NET since 2.0 or maybe even since 1.0 that is used by the Convert class. This interface demands methods like ToInt32, etc.
为了保持一致性:在。net中有一个IConvertible接口，从2.0开始，或者从1.0开始，转换类就使用了这个接口。这个接口需要ToInt32等方法。

Code Generation (more details): The usual method to generate code back in .NET 2.0 times was System.CodeDOM as it provides means to reuse the same code generator for multiple languages, most prominently VB.NET and C#. In CodeDOM, you don't need to know of what type a given expression is to call a method, you can simply create a CodeMethodCallExpression given on the target object expression and the methods name. On the other hand, many cast operators such like C#s as operator are not supported by CodeDOM.

代码生成(更多细节):通常在. net 2.0时代生成代码的方法是System。CodeDOM提供了为多种语言重用相同代码生成器的方法，最突出的是VB。NET和c#。在CodeDOM中，您不需要知道给定表达式调用方法的类型，只需在目标对象表达式和方法名上创建一个CodeMethodCallExpression。另一方面，许多转换操作符如c# s作为操作符不受CodeDOM的支持。

As a consequence, it is often hard to know the type of a given code expression in CodeDOM. This totally makes sense as many methods that an expression may involve are also part of the generated code and thus unknown at generation time. However, in some cases you need a particular expression converted to a given type, such as System.Int32. I can imagine this actually happened for typed data sets, although I am not 100% sure. Because Convert.ToInt32 exists, the generator does not need to know whether a given expression is of type System.Int32 or not. When the compiler compiles the generated code, all the methods signatures are available and the compiler may figure out that the type of the expression is System.Int32 and call the appropriate overload.

因此，通常很难知道CodeDOM中给定代码表达式的类型。这完全说得通，因为表达式可能涉及的许多方法也是生成代码的一部分，因此在生成时是未知的。但是，在某些情况下，您需要将特定表达式转换为给定类型，例如System.Int32。我可以想象在类型化数据集中确实发生了这种情况，尽管我不是100%确定。因为转换。ToInt32存在，生成器不需要知道给定表达式是否为类型系统。Int32与否。当编译器编译生成的代码时，所有的方法签名都是可用的，编译器可能会发现表达式的类型是System。Int32并调用适当的过载。

On the other side, the JIT compiler will detect that the method Convert.ToInt32 will simply return its argument. But as the method is not virtual, the methods body can be inserted into the callers code instead of calling Convert.ToInt32 as the overhead of calling the method would be much higher than the method body.

另一方面，JIT编译器将检测方法转换。ToInt32只会返回它的参数。但是由于方法不是虚拟的，所以可以将方法主体插入到调用者代码中，而不是调用Convert。ToInt32作为调用方法的开销要比方法主体高得多。

#2

Only the API designers know.

只有API设计人员知道。

If I had to make a guess, I would guess it is for the sake of consistency - for example, when you are using reflection to dynamically create calls, it's easier if you can make the assumption that every Convert.ToX(Y) combination exists for any primitive types X and Y.

如果我必须进行猜测，我就会猜测这是出于一致性的考虑——例如，当您使用反射来动态创建调用时，如果您可以假设对于任何原始类型X和Y都存在每个Convert.ToX(Y)组合，那么这将更容易。

#3

We can derive one possible answer from usages of ToInt32(Int32) in the framework classes.

我们可以从框架类中的ToInt32(Int32)的用法中得到一个可能的答案。

E.g. System.Activities.DurableInstancing.SerializationUtilities

例如System.Activities.DurableInstancing.SerializationUtilities

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

and System.ComponentModel.Design.CollectionEditor

和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));

In both cases we can see that the type of the property or expression is currently Int32, but there's a reasonable expectation that /maybe/ that type might be different on different platforms, CPU architectures, future versions of the framework etc.

在这两种情况下，我们都可以看到属性或表达式的类型当前是Int32，但是有一个合理的期望，即/可能/可能在不同的平台、CPU架构、框架的未来版本等方面有所不同。

So my proposed answer is that it exists as a sort of future proofing of the source code, to allow it to compile without modification even when some key 'entities' (such as window X and Y coords) change type.

因此，我的建议是，它作为源代码的一种未来验证而存在，以便在某些关键的“实体”(如窗口X和Y coords)更改类型时，它可以不加修改地进行编译。

#4

Common Language Runtime use internally the IConvertible interface. As the CLR base types are Boolean, SByte, Byte, Int16, UInt16, Int32, UInt32, Int64, UInt64, Single, Double, Decimal, DateTime, Char y String, there are an Implementation for each one of them in Convert class.

公共语言运行时在内部使用IConvertible接口。由于CLR基类型是布尔型、SByte型、Byte型、Int16型、Int32型、UInt32型、Int64型、UInt64型、Single型、Double型、Decimal型、DateTime型、Char型字符串，因此在Convert类中每个类型都有一个实现。

But, for example, Convert.toBoolean(DateTime) always return an Exception, by design.

但是，例如，Convert.toBoolean(DateTime)总是通过设计返回一个异常。

#5

Here's the method description:

方法描述:

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

Only thing I can think of is that it's a shortcut/pass-through if the input is already an int. It's likely much more efficient than if an int was passed into Convert.ToInt32(object).

只有我能想到的是，如果输入已经是int，那么它就是一个快捷方式/传递方式。

#1