隐藏C++成员函数的原因

Reason for C++ member function hiding

本文关键字：函数 C++ 成员 隐藏      更新时间：2023-10-16

可能的重复项：
名称隐藏和脆弱的基础问题

我熟悉涉及成员函数隐藏的规则。 基本上，具有与基类函数同名的函数的派生类实际上不会重载基类函数 - 它完全隐藏了它。

struct Base
{
    void foo(int x) const
    {
    }
};
struct Derived : public Base
{
    void foo(const std::string& s) { }
};

int main()
{
    Derived d;
    d.foo("abc");
    d.foo(123); // Will not compile! Base::foo is hidden!
}

因此，您可以通过using声明来解决此问题。 但我的问题是，基类函数隐藏的原因是什么？ 这是标准委员会的"功能"还是"错误"？ 是否有一些技术原因导致编译器在找不到d.foo(123)匹配项时无法在 Base 类中查找匹配重载？

名称查找的工作原理是在当前范围内查找匹配的名称，如果未找到任何内容，则在封闭范围内查找，如果未找到，则在封闭范围内查找，依此类推，直到到达全局命名空间。

这不是特定于类的，您可以在此处获得完全相同的名称：

#include <iostream>
namespace outer
{
  void foo(char c) { std::cout << "outern"; }
  namespace inner
  {
    void foo(int i) { std::cout << "innern"; }
    void bar() { foo('c'); }
  }
}
int main()
{
  outer::inner::bar();
}

尽管outer::foo(char)与呼叫foo('c')名称查找在找到outer::inner::foo(int)后停止（即 outer::foo(char)是隐藏的），因此程序打印inner.

如果未隐藏成员函数名称，则意味着类作用域中的名称查找与非类作用域的行为不同，这将不一致且令人困惑，并使C++更难学习。

因此，没有技术原因无法更改名称查找规则，但必须为成员函数和其他类型的名称查找更改它们，这将使编译器变慢，因为它们必须继续搜索名称即使在当前范围内找到匹配的名称。明智的是，如果当前范围内有一个名称，则可能是您想要的名称。作用域中的调用A可能希望在该作用域中查找名称，例如，如果两个函数位于同一命名空间中，则它们可能是相关的（同一模块或库的一部分），因此，如果一个函数使用另一个函数的名称，则可能意味着调用同一作用域中的函数。如果这不是您想要的，请使用显式限定或 using 声明来告诉编译器另一个名称应该在该范围内可见。

这是标准委员会的"功能"还是"错误"？

这绝对不是错误，因为它在标准中明确规定。这是一个功能。

当编译器找不到 d.foo（123） 的匹配项时，编译器无法在 Base 类中查找匹配重载，这是否有一些技术原因？

从技术上讲

，编译器可以在基类中查找。从技术上讲。但如果是这样，它将打破标准设定的规则。

但我的问题是，基类函数隐藏的原因是什么？

除非委员会有人给出答案，否则我认为我们只能推测。基本上，有两种选择：

    如果我在派生类中声明一个同名的函数
  • ，请保留基类的同名函数，通过派生类直接访问
  • 不要

它可以通过掷硬币来确定（...好吧，也许不是）。

通常，想要与基类同名的函数的原因是什么？有不同的功能 - 您更有可能使用多态性。为了处理不同的情况（不同的参数），如果基类中不存在这些情况，则策略模式可能更适合处理作业。因此，当您实际想要隐藏函数时，函数隐藏很可能会生效。您对基类实现不满意，因此您提供了自己的基类，可以选择使用 using ，但仅在您愿意的时候。

我认为这只是一种机制，让你在拥有具有相同名称和不同签名的函数之前三思而后行。

我相信

@Lol4t0几乎是正确的，但我会更强烈地陈述事情。如果你允许这样做，你最终会有两种可能性：要么在整个语言中进行许多其他更改，要么你最终得到几乎完全破坏的东西。

你为允许它工作而进行的其他更改是彻底改变重载的完成方式 - 你必须至少改变所采取步骤的顺序，可能还有步骤本身的细节。现在，编译器查找名称，然后形成重载集，解析重载，然后检查对所选重载的访问。

为了使这项工作更加顺利，您几乎必须更改它以首先检查访问权限，并且只将可访问的功能添加到重载集。这样，至少@Lol4t0答案中的示例可以继续编译，因为Base::foo永远不会被添加到重载集中。

但是，这仍然意味着添加到基类的接口可能会导致严重的问题。如果Base最初不包含foo，并且添加了公共foo，那么main对d.foo()的调用会突然做一些完全不同的事情，并且（再次）它将完全不受写Derived的人的控制。

为了解决这个问题，你几乎必须对规则进行一个相当根本的改变：禁止函数参数的隐式转换。除此之外，您还需要更改重载分辨率，以便在平局的情况下，函数的最派生/最本地版本优先于派生较少/外部作用域。有了这些规则，对d.foo(5.0)的召唤就永远无法解决Derived::foo(int)。

然而，这只会留下两种可能性：要么调用自由函数的规则与调用成员函数的规则不同（隐式转换只允许自由函数），要么完全丢弃与 C 的所有兼容性（即，也禁止所有函数参数中的隐式转换，这将破坏大量现有代码）。

总结一下：要在不完全破坏语言的情况下更改此设置，您还必须进行许多其他更改。几乎可以肯定的是，创建一种以这种方式工作的语言是可能的，但是当你完成时，它不会C++一个小的更改 - 它将是一种完全不同的语言，不太像C++或C，或其他任何东西。

我只能提出，这个决定是为了让事情变得更简单。

想象一下，派生函数将重载基数。那么，下面的代码是应该生成编译错误，还是使用 Derived s 函数？

struct Base
{
private:
    void foo(float);
}
struct Derived: public Base
{
public:
    void foo(int);
}
int main()
{
    Derived d;
    d.foo(5.0f);
}

根据现有的重载行为，这应该会产生错误。

现在想象一下，在第一个版本中Base没有foo(float).在第二个版本中，它出现了。现在改变基类中断接口的派生实现。

如果您是Derived的开发人员并且无法影响Base的开发人员并且许多客户端使用您的界面，那么您现在的情况很糟糕。

相关文章：