关于C#中不明确调用的问题

发布于 2024-07-22 12:32:30 字数 800 浏览 4 评论 0原文

我有一个问题,虽然不是真正的问题,但让我有点好奇。

我有一个类,其中有两种方法。 一种是静态方法,另一种是实例方法。 这些方法具有相同的名称。

public class BlockHeader
{
    public static BlockHeader Peek(BinaryReader reader)
    {
        // Create a block header and peek at it.           
        BlockHeader blockHeader = new BlockHeader();
        blockHeader.Peek(reader);
        return blockHeader;
    }

    public virtual void Peek(BinaryReader reader)
    {
        // Do magic.
    }
}

当我尝试构建我的项目时,我收到一条错误消息:

调用之间不明确 以下方法或属性: 'MyApp.BlockHeader.Peek(System.IO.BinaryReader)' 和 'MyApp.BlockHeader.Peek(System.IO.BinaryReader)'

我知道方法签名实际上是相同的,但我看不出如何直接从实例成员调用静态方法。

我认为这是有一个很好的理由的,但是有人知道这个理由是什么吗?

I have a question that's not really a problem, but something that made me a little curious.

I have a class with two methods in it. One is a static method and the other one is an instance method. The methods have the same name.

public class BlockHeader
{
    public static BlockHeader Peek(BinaryReader reader)
    {
        // Create a block header and peek at it.           
        BlockHeader blockHeader = new BlockHeader();
        blockHeader.Peek(reader);
        return blockHeader;
    }

    public virtual void Peek(BinaryReader reader)
    {
        // Do magic.
    }
}

When I try to build my project I get an error saying:

The call is ambiguous between the
following methods or properties:
'MyApp.BlockHeader.Peek(System.IO.BinaryReader)'
and
'MyApp.BlockHeader.Peek(System.IO.BinaryReader)'

I know that the method signatures are virtually the same, but I can't see how I possibly could call a static method directly from an instance member.

I assume that there is a very good reason for this, but does anyone know what that reason is?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

无力看清 2024-07-29 12:32:30

C# 设计的一般策略是强制您指定可能存在歧义的地方。 面对允许人们随时调整事物是否静态的重构工具,这种立场非常好——尤其是对于这样的情况。 您会看到许多其他类似的情况(覆盖与虚拟、新的阴影等)。

一般来说,消除这种混乱的空间将使代码更加清晰,并迫使您保持秩序。

编辑: Eric Lippert 的一篇好文章讨论了另一个原因这种歧义导致了您看到的错误

The general policy of the C# design is to force you to specify wherever there is potential ambiguity. In the face of refactoring tools that allow one to rejig whether things are static or not at the drop of a hat, this stance is great - especially for cases like this. You'll see many other cases like this (override vs virtual, new for shadowing etc.).

In general, removing this type of room for confusion will make the code clearer and forces you to keep your house in order.

EDIT: A good post from Eric Lippert discusses another reason for this ambiguity leading to the error you saw

度的依靠╰つ 2024-07-29 12:32:30

以下是 C# 3.0 语言规范的摘录。

方法的签名在声明该方法的类中必须是唯一的。 方法的签名由方法的名称、类型参数的数量及其参数的数量、修饰符和类型组成。 方法的签名不包含返回类型。

“static”修饰符不是签名的一部分,因此您的示例违反了唯一签名的规则。

但我不知道该规则背后的原因。

Here's a excerpt from the C# 3.0 language specification.

The signature of a method must be unique in the class in which the method is declared. The signature of a method consists of the name of the method, the number of type parameters and the number, modifiers, and types of its parameters. The signature of a method does not include the return type.

The 'static' modifier is not part of the signature so your example violates this rule of unique signatures.

I don't know the reason behind the rule, though.

我们的影子 2024-07-29 12:32:30

我认为没有技术原因不允许这样做,但这样做更多是为了保护程序员免受自己的伤害。 考虑以下示例:

public static void Main()
{
  BlockHeader BlockHeader = new BlockHeader();
  BlockHeader.Peek();
}

上面的示例完全有效,但是如果允许您描述的情况,它是否可读? 眨眼间你能看到是调用了实例方法还是静态方法吗?

I think there's no technical reason to disallow it, but it is done more so to protect the programmer from himself. Consider the following example:

public static void Main()
{
  BlockHeader BlockHeader = new BlockHeader();
  BlockHeader.Peek();
}

The example above is perfectly valid, but if the situation you describe were allowed, would it be readable? Could you see, in the blink of an eye, whether the instance method or the static method was called?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文