问.Net隐式转换指南

EN

第一个并不像你想象的那么简单。下面是一个例子：

using System;

class Test
{
    static void Main()
    {
        long firstLong = long.MaxValue - 2;
        long secondLong = firstLong - 1;

        double firstDouble = firstLong;
        double secondDouble = secondLong;

        // Prints False as expected
        Console.WriteLine(firstLong == secondLong);

        // Prints True!
        Console.WriteLine(firstDouble == secondDouble);        
    }
}

就我个人而言，我很少创建自己的隐式转换。我对框架中的那些很满意，但我很少觉得添加自己的框架会让生活变得更好。(一般来说，值类型也是如此。)

编辑:实际上回答一下这个问题，可能值得阅读conversion operators part of the Microsoft class library design guidelines。

我绝对同意第一种方法--第二种方法(“永不说永远不会”)，但不会因为第三种方法而兴奋；除此之外，它在结构和类之间产生了不必要的区别。在某些情况下，使用隐式转换可以极大地简化调用约定。

对于显式转换，所有事情都是可能的。

不过，您并不经常需要编写转换运算符。在许多情况下，显式运算符更有用，因为它们可以在条件不正确时中断(例如，对于Nullable<T>，如果它们没有值)。

如果你只支持自己类型的对象之间的隐式转换，我建议你应该决定什么“公理”应该应用于这样的转换(例如，如果a==b、b==c和a==c都是合法的，其中两个是真的，那么第三个也必须是真的)，然后确定一组最有用的转换，使这些公理成立。我在我的博客http://supercatnet.blogspot.com/2013/09/axioms-of-implicit-type-conversion.html上讨论了四个有用的公理(不幸的是，.NET框架包含了违反这四个公理的转换，而不允许不需要的转换)。

要考虑的重要一点是，在大多数情况下，隐式转换到不精确类型的风险比从不精确类型转换的风险要小，但有一个明显的例外:如果将某种更精确的类型提供给具有重载的方法或运算符，该方法或运算符同时接受更精确的类型和可以转换为的较不精确的类型，则几乎不可避免地会出现某种程度的“惊人”行为，除非可以使隐式转换变得不可能[例如，程序员编写if (someLong == someFloat)的行为可能令人惊讶，但这并不是因为隐式long到float转换的精度损失是惊人的，而是因为至少有六种不同的方法可以比较long和float(*)，并且编译器可能附加到直接比较的任何含义都会让那些期望其他东西的人感到惊讶。我所知道的避免这种惊讶的唯一解决方案是提供重载来显式地覆盖所有不明确的情况，并用[Obsolete()]标记来标记它们。这样做可能会有些笨拙，但将提供能够满足所有四个公理的实质性优势。

(*)程序员可能想要测试long是否等于四舍五入到最近的浮点值、向零截断或向负无穷大的浮点值；或者，程序员可能想要测试float是否代表long，float和long是否具有相同的额定值，或者float和long是否都会转换为相同的double。