ami*_*mit 5 c++ virtual overriding access-specifier
构建基类接口的理由很充分,所有虚函数都是私有或受保护的(参见本文).但是,如何防止派生类(可能在外部客户端手中)使私有虚函数成为公共?在Virtually Yours中,作者谈到了这个问题,但没有讨论解决方案.
编辑:从您的答案和我之前的想法,似乎没有办法阻止这一点.但是因为在这种情况下,很容易出错(客户端肯定会触及受保护的虚函数),编译器会警告这种用法是有意义的.我试着用g ++测试它.首先,我写道:
class A {
        protected:
        virtual void none() { return; }
};
class B: public A {
        public:
        void none() { return; }
};
g++ -c -Wall -pedantic file.cpp编译没有错误.添加-Weffc++发出警告:warning: ‘class A’ has virtual functions and accessible non-virtual destructor这是有道理的.添加虚拟析构函数后,没有警告.因此,这个容易出错的案例没有任何警告.
Jer*_*fin 12
正如Bjarne所说,C++中的访问控制旨在防止墨菲,而不是马基雅维利.一般情况也是如此 - 它的特征是为了防止意外事故,而不是故意做错事的人.
在某种程度上,使用C++意味着至少对可以访问源代码的其他人有一定程度的信任.如果他们想要足够严重,他们可以通过各种方式搞砸事情,而且你无法做很多事情来制止它们.如果您想对代码的使用方式设置真正的限制,那么C++是您的错误语言.
编辑:这根本不是一个"论据" - 它只是指出做出决定的依据.由于我在回答上一个问题后得到了D&E的副本,如果在这里,我会输入更多的一个1:
允许一个有用的功能比防止每次误用更重要:你可以用任何语言编写糟糕的程序.重要的是要尽量减少意外滥用功能的可能性,并且花费了大量精力来确保C++构造的默认行为是合理的或导致编译时错误.例如,默认情况下,所有函数参数类型都会被检查 - 即使是在不同的编译边界 - 并且默认情况下所有类成员都是私有的.然而,系统编程语言不能阻止确定的程序员破坏系统,因此设计工作更好地用于提供编写好程序的工具而不是防止不可避免的坏程序.从长远来看,程序员似乎在学习.这是旧C"信任程序员"口号的变种.存在各种类型检查和访问控制规则,以允许类提供者清楚地说明用户的期望,以防止事故.这些规则并非旨在防止故意违反(第2.10节).
在§2.10中,他说,除其他外:
保护系统的任务是确保任何此类违反类型系统的行为都是明确的,并尽量减少对此类违规行为的需求.
这些目标似乎已在这里得到满足 - 公开受保护的基类成员肯定需要在派生类中进行明确的操作,并且在编写C++ 20多年后,我不记得曾经需要(甚至想要)这样做.
1 §4.3,编.115,116.