class X
{
protected:
void protectedFunction() { cout << "I am protected" ; }
};
class Y : public X
{
public:
using X::protectedFunction;
};
int main()
{
Y y1;
y1.protectedFunction();
}
这样我就能够暴露基类的一个函数。
class Y : public X
{
public:
void doA()
{
protectedFunction();
}
};
int main()
{
Y y1;
y1.doA();
}
我认为没有必要担心这个问题。
受保护的函数是继承树中可重用逻辑的一部分。如果有一些内部逻辑或限制，您可以隐藏它们；或者像您的情况一样，如果您确定这不会对任何人造成伤害，您也可以将其公开。
确实如此，这也是为什么protected受到了相当多的批评。
C++的创造者Bjarne Stroustrup在他的杰作《C++设计与演化》中为此感到遗憾：
我对protected的担忧恰恰在于它使得过度使用共同基类变得太容易，就像人们可能会懒散地使用全局数据一样......回想起来，我认为protected是一个“好论点”和流行思想克服了我的更好判断和接受新特性的经验法则的情况。
protectedFunction()是受保护的。您可以从派生类中自由调用它，因此您可以直接从Y的公共成员调用它，并从main()调用此公共成员。
如果使用私有方法进行这样的操作，会出现问题...（编辑后更清晰）。
第一步：
要使用公共方法，您需要有一个Y实例。以下内容将无法正常工作：
int main()
{
X y1;
y1.protectedFunction();
}
#define protected public // illegal
#include "X.h"
//...
X y1;
y1.protectedFunction();
class Y : public X
{
public:
void protectedFunction() {
X::protectedFunction();
}
};
一旦方法被保护，就会提供给派生类自由使用。 using 声明的意图并不是改变继承方法的访问权限，而是避免方法隐藏所带来的问题（如果在类型 Y 中定义了一个不同的重载，则 X 中的公共方法将被隐藏）。
现在，根据语言规则，它确实可以用于更改“使用”的方法的访问级别，就像您的示例一样，但实际上这并没有在系统中打开任何漏洞。最终，派生类不能比以前做更多的事情。
如果实际问题是特定用法是否从设计角度违反了封装性（其中设计在这里是应用程序设计，而不是语言设计），那么很可能是。就像将内部数据或方法公开一样。如果 X 的初始设计者将其设计为受保护的，则实现 Y 的人很可能不希望其成为公共...（或提供一个委托方法以达到相同的目的）
不，我真的看不出问题。
你可以这样做，而不是使用using：
class X
{
protected:
void protectedFunction() { cout << "i am protected" ; }
};
class Y : public X
{
public:
void protectedFunction() { X::protectedFunction(); }
};
类的设计者应该知道，声明成员函数或变量（尽管所有变量都应该是私有的）为protected，这基本上与将其声明为public相同（正如你展示的那样，很容易获取对受保护信息的访问权限）。 在这种情况下，当在基类中实现这些函数时，必须小心处理“意外”使用。这不违反封装性，因为您可以访问它并公开它。
protected只是一种更复杂的声明某些东西为public的方式！
个人认为这个问题应该更多地作为一个设计问题而不是技术问题来回答。
我会问：“保护方法的初衷是什么？”它是只有子类应该调用的方法，还是子类应该覆盖的方法？然而，这可能是一个在通用基类中不期望出现的方法，但在子类中可能期望出现。对于基类的客户端来说，他们从未知道那个受保护的方法。子类的创建者选择扩展协议，现在该受保护的方法是公开的。问题实际上不应该是C++是否允许，而是它对于您的类、协议和未来维护者是否正确。当然，这可能是一种不好的味道，但你真的需要根据涉及到的使用情况将其变得正确。
如果您确实将受保护的方法公开，请确保为维护者提供内部文档，解释为什么做出这个特定决定的基础。
一般来说，为了安全起见，正如之前的贡献者提到的，您可能希望在子类中使用委托函数（具有不同的名称）。因此，您可以使用“getAtIndex(int)”之类的代替“get(int)”，这样您可以更轻松地在未来重构/保护/抽象/文档化。
protected封装不能被强制性地打破，我认为这并不是语言的失败。 - Andrew Noyes