为什么 C# 不允许像 C++ 这样的非成员函数 [英] Why C# is not allowing non-member functions like C++
问题描述
C# 不允许编写非成员函数，每个方法都应该是类的一部分.我认为这是所有 CLI 语言的限制.但是我错了，我发现 C++/CLI 支持非成员函数.编译时，编译器会将该方法作为某个未命名类的成员.
C# will not allow to write non-member functions and every method should be part of a class. I was thinking this as a restriction in all CLI languages. But I was wrong and I found that C++/CLI supports non-member functions. When it is compiled, compiler will make the method as member of some unnamed class.
这是 C++/CLI 标准所说的，
Here is what C++/CLI standard says,
[注意:CLI 将非成员函数视为某个未命名类的成员；但是，在 C++/CLI 源代码中，不能使用该类名显式限定此类函数.尾注]
[Note: Non-member functions are treated by the CLI as members of some unnamed class; however, in C++/CLI source code, such functions cannot be qualified explicitly with that class name. end note]
未指定元数据中非成员函数的编码.[注意:这不会导致互操作问题，因为此类功能无法公开可见.尾注]
The encoding of non-member functions in metadata is unspecified. [Note: This does not cause interop problems because such functions cannot have public visibility. end note]
所以我的问题是为什么 C# 不实现这样的东西?或者你认为不应该有非成员函数，每个方法都应该属于某个类?
So my question is why don't C# implement something like this? Or do you think there should not be non-member functions and every method should belong to some class?
我的观点是有非成员函数支持，有助于避免污染类的接口.
My opinion is to have non-member function support and it helps to avoid polluting class's interface.
有什么想法......?
Any thoughts..?
推荐答案
查看此博文:
http://blogs.msdn.com/ericlippert/archive/2009/06/22/why-doesn-tc-implement-top-level-methods.aspx
(...)
有人问我为什么 C# 不实现功能 X?"每时每刻.答案总是一样的:因为没有人设计、指定、实施、测试、记录和发布该功能.所有这六件事都是使功能发生所必需的.所有这些都花费了大量的时间、精力和金钱.功能并不便宜，而且我们非常努力地确保我们只发布那些在时间、精力和金钱预算有限的情况下为我们的用户带来最大利益的功能.
I am asked "why doesn't C# implement feature X?" all the time. The answer is always the same: because no one ever designed, specified, implemented, tested, documented and shipped that feature. All six of those things are necessary to make a feature happen. All of them cost huge amounts of time, effort and money. Features are not cheap, and we try very hard to make sure that we are only shipping those features which give the best possible benefits to our users given our constrained time, effort and money budgets.
我知道这样一个笼统的答案可能无法解决具体问题.
I understand that such a general answer probably does not address the specific question.
在这种特殊情况下，过去明显的用户利益不足以证明随之而来的语言的复杂性是合理的.通过限制不同语言实体如何相互嵌套，我们 (1) 将合法程序限制为通用、易于理解的风格，以及 (2) 可以定义可理解、可指定、可实现、可测试的标识符查找"规则并且可记录.
In this particular case, the clear user benefit was in the past not large enough to justify the complications to the language which would ensue. By stricting how different language entities nest inside each other we (1) restrict legal programs to be in a common, easily understood style, and (2) make it possible to define "identifier lookup" rules which are comprehensible, specifiable, implementable, testable and documentable.
通过限制方法体总是在结构体或类中，我们可以更容易地推断调用上下文中使用的非限定标识符的含义；这样的东西始终是当前类型(或基类型)的可调用成员.
By restricting method bodies to always be inside a struct or class, we make it easier to reason about the meaning of an unqualified identifier used in an invocation context; such a thing is always an invocable member of the current type (or a base type).
(...)
以及此后续帖子:
http://blogs.msdn.com/ericlippert/archive/2009/06/24/it-already-is-a-scripting-language.aspx
(...)
与所有设计决策一样，当我们面临许多相互竞争、引人注目、有价值且不可组合的想法时，我们必须找到可行的折衷方案.我们不会这样做，除非考虑所有可能性，这就是我们在本例中所做的.
Like all design decisions, when we're faced with a number of competing, compelling, valuable and noncompossible ideas, we've got to find a workable compromise. We don't do that except by considering all the possibilites, which is what we're doing in this case.
(强调来自原文)
这篇关于为什么 C# 不允许像 C++ 这样的非成员函数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
