【发布时间】:2014-01-14 02:20:39
【问题描述】:
我喜欢 C# 中的可选参数。但是当在构造函数中使用它们时,签名看起来(或可以看起来)像默认构造函数,使用泛型和new()-constraint 时事情会变得很奇怪:
class A<T> where T : new() { }
class B : A<B>
{
public B(bool b = false) { }
// 'B' must be a non-abstract type with a public **parameterless** constructor
// in order to use it as parameter 'T' in the generic type or metho A<T>
}
在上面的示例中,编译器抱怨说没有无参数构造函数,迫使我添加类似:public B() : this(false) { }(实际上使可选版本变得多余)。
真的吗?我可以new B(),那有什么问题吗? (不是在编译过程中“扩展”了可选参数的方法吗?)我错过了一点吗?我知道提出这样的问题可能会导致诸如“这是一个设计决定”或“它更容易实现”之类的答案,但在大多数情况下,我只是忽略了一些东西。 :-)
【问题讨论】:
-
不确定你的问题是什么:显然带有可选参数的构造函数是 not 没有参数的构造函数。那么您是在问为什么做出这个决定(不太可能得到扩展答案),如何解决它(但您已经发布了代码示例)或完全不同的东西?
-
那么,是什么让像上面显示的构造函数与没有参数的构造函数不同,只要它可以在没有参数的情况下调用?也许我缺乏对可选参数如何编译/解释的理解。我的问题实际上是:这种区分是否有更深层次的含义? (当然,如果没有,这个问题在某种程度上毫无意义。)
-
@MarcinJuraszek 建议的答案包含非常详细的解释。简短 -
public B(bool b = false)不会在任何时候(编译/运行时)自动创建public B()- 所以类不包含无参数构造函数。 -
哈!感谢您的链接 - 这几乎是答案:问题是,可选参数是编译器功能,因此被转换为 CLR 的具有参数和属性(具有默认值)的方法。由于通用约束是 CLR 的主题,因此无法针对这种情况自动评估它们。 (至少只要 CLR 将来不支持可选参数,那么可能也会支持这种构造。)
标签: c# generics constructor compiler-errors optional-parameters