在编译时将继承限制为所需数量的类
我们有一个限制,一个类不能充当超过 7 个类的基类。 有没有办法在编译时强制执行上述规则?
我知道 Andrew Koenig 的 Usable_Lock 技术可以防止类被继承,但只有当我们尝试实例化该类时它才会失败。 难道在派生自身的时候就不能这样做吗?
基类可以知道谁是它的孩子。 所以我想我们可以声明一个朋友的组合 类并封装它们以强制执行此规则。 假设我们尝试这样的事情
class AA {
friend class BB;
private:
AA() {}
~AA() {}
};
class BB : public AA {
};
class CC : public AA
{};
CC 类的派生将生成编译器警告 abt inaccessible dtor。 然后我们可以标记 使用编译器调整将此类警告视为错误(例如将所有警告标记为错误),但我不想依赖此类技术。
另一种方法,但对我来说看起来相当笨拙是: -
class B;
class InheritanceRule{
class A {
public:
A() {}
~A() {}
};
friend class B;
};
class B {
public:
class C : public InheritanceRule::A
{};
};
class D : public InheritanceRule::A{};
类 D 的派生将被标记为编译器错误,这意味着要派生的所有类都应在类 B 内派生。这将至少允许检查类的数量源自 A 类,但不会阻止任何人添加更多。
这里有人有办法做到吗? 如果基类不需要知道谁是它的孩子,那就更好了。
注意:充当基类的类本身可以被实例化(它不是抽象的)。
提前致谢,
EDIT-1:根据 jon.h 的评论,稍作修改
// create a template class without a body, so all uses of it fail
template < typename D>
class AllowedInheritance;
class Derived; // forward declaration
// but allow Derived by explicit specialization
template<>
class AllowedInheritance< Derived> {};
template<class T>
class Base : private AllowedInheritance<T> {};
// privately inherit Derived from that explicit specialization
class Derived : public Base<Derived> {};
// Do the same with class Fail Error
// it has no explicit specialization, so it causes a compiler error
class Fail : public Base<Fail> {}; // this is error
int main()
{
Derived d;
return 0;
}
We have a restriction that a class cannot act as a base-class for more than 7 classes.
Is there a way to enforce the above rule at compile-time?
I am aware of Andrew Koenig's Usable_Lock technique to prevent a class from being inherited but it would fail only when we try to instantiate the class. Can this not be done when deriving itself?
The base-class is allowed to know who are its children. So i guess we can declare a combination of friend
classes and encapsulate them to enforce this rule. Suppose we try something like this
class AA {
friend class BB;
private:
AA() {}
~AA() {}
};
class BB : public AA {
};
class CC : public AA
{};
The derivation of class CC would generate a compiler warning abt inaccessible dtor. We can then flag
such warnings as errors using compiler tweaks (like flag all warnings as errors), but i would not like to rely on such techniques.
Another way, but to me looks rather clumsy is:-
class B;
class InheritanceRule{
class A {
public:
A() {}
~A() {}
};
friend class B;
};
class B {
public:
class C : public InheritanceRule::A
{};
};
class D : public InheritanceRule::A{};
The derivation of class D will be flagged as a compiler error, meaning all the classes to be derived should be derived inside class B. This will allow atleast an inspection of the number of classes derived from class A but would not prevent anyone from adding more.
Anyone here who has a way of doing it ? Better still if the base-class need not know who are its children.
NOTE: The class which acts as a base-class can itself be instantiated (it is not abstract).
Thanks in advance,
EDIT-1: As per Comment from jon.h, a slight modification
// create a template class without a body, so all uses of it fail
template < typename D>
class AllowedInheritance;
class Derived; // forward declaration
// but allow Derived by explicit specialization
template<>
class AllowedInheritance< Derived> {};
template<class T>
class Base : private AllowedInheritance<T> {};
// privately inherit Derived from that explicit specialization
class Derived : public Base<Derived> {};
// Do the same with class Fail Error
// it has no explicit specialization, so it causes a compiler error
class Fail : public Base<Fail> {}; // this is error
int main()
{
Derived d;
return 0;
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
抱歉,我不知道如何使用编译器强制执行任何此类限制。
就我个人而言,我不会费心尝试将规则强加到代码本身中 - 您正在用与代码正在执行的操作无关的内容来混乱代码 - 这不是干净的代码。
我不会试图跳过障碍,而是会尝试放宽这条规则。 相反,它应该是一个可以在必要时被打破并与团队中其他人达成一致的指导方针。
当然,我不知道你在做什么,所以规则可能是合适的,但总的来说可能不是。
任何规定你绝对不能做 x 或必须总是做 y 的编程“规则”几乎总是错误的! 请注意其中的“几乎”一词。
有时您可能需要超过 7 个派生类 - 那么您会做什么? 跳过更多的圈。 另外,为什么是7? 为什么不是6个或8个? 这太武断了——这是糟糕规则的另一个迹象。
如果你必须这样做,正如 JP 所说,静态分析可能是更好的方法。
Sorry, I don't know how to enforce any such limit using the compiler.
Personally I wouldn't bother trying to force the rule into the code itself - you are cluttering the code with stuff that has nothing to do with what the code is doing - it's not clean code.
Rather than jumping through hoops, I'd try to get that rule relaxed. Instead it should be a guideline that could be broken if necessary and in agreement with others in the team.
Of course, I lack the knowledge of exactly what you're doing so the rule could be appropriate, but in general it probably isn't.
Any programming "rule" that says you must never do x or you must always do y is almost always wrong! Notice the word "almost" in there.
Sometimes you might need more than 7 derived classes - what do you do then? Jump through more hoops. Also, why 7? Why not 6 or 8? It's just so arbitrary - another sign of a poor rule.
If you must do it, as JP says, static analysis is probably the better way.
我累得要命,几乎睁不开眼睛,所以可能有一种更优雅的方法来做到这一点,而且我当然不赞同 Base 最多应该有七个子类的奇怪想法。
来自 jon.h 的评论:
事实并非如此。 但OP最初的例子也没有。
致OP:您对我答案的修改几乎是Coplien的“好奇重复模板模式”的直接应用< /a>]
我也考虑过这一点,但问题是
衍生1 : pubic base<衍生1>
和衍生2 : 公共基础<衍生2><之间没有继承关系/code>,因为
base<衍生1>
和base<衍生2>
是两个完全不相关的类。如果您唯一关心的是实现的继承,这没有问题,但如果您想要接口的继承,您的解决方案就会打破这一点。
我认为有一种方法可以同时获得继承和更清晰的语法; 正如我提到的,当我编写解决方案时我非常累。 如果不出意外,在您的示例中将 RealBase 设为 Base 的基类是一个快速解决方案。
可能有很多方法可以清理这个问题。 但我想强调的是,我同意 markh44 的观点:尽管我的解决方案更清晰,但我们仍然使代码变得混乱,以支持毫无意义的规则。 仅仅因为这可以做到,并不意味着它应该这样做。
如果所讨论的基类已有十年历史并且太脆弱而无法继承,那么真正的答案就是修复它。
I'm tired as crap, can barely keep my eyes open, so there's probably a more elegant way to do this, and I'm certainly not endorsing the bizarre idea that a Base should have at most seven subclasses.
Comment from jon.h:
It doesn't. But then neither did the OP's original example.
To the OP: your revision of my answer is pretty much a straight application of Coplien's "Curiously recurring template pattern"]
I'd considered that as well, but the problem with that there's no inheritance relationship between a
derived1 : pubic base<derived1>
and aderived2 : pubic base<derived2>
, becausebase<derived1>
andbase<derived2>
are two completely unrelated classes.If your only concern is inheritance of implementation, this is no problem, but if you want inheritance of interface, your solution breaks that.
I think there is a way to get both inheritance and a cleaner syntax; as I mentioned I was pretty tired when I wrote my solution. If nothing else, by making RealBase a base class of Base in your example is a quick fix.
There are probably a number of ways to clean this up. But I want to emphasize that I agree with markh44: even though my solution is cleaner, we're still cluttering the code in support of a rule that makes little sense. Just because this can be done, doesn't mean it should be.
If the base class in question is ten years old and too fragile to be inherited from, the real answer is to fix it.
许多不同的静态代码分析工具都提供有关继承层次结构的信息。 我不会尝试在代码中处理它,而是研究一个可以为继承层次结构设置一些规则的工具,如果不遵循这些规则,则构建失败。 可能会花费一点美元,并且您可能必须编写自定义规则(我已经看到了继承深度,但没有看到您想要的继承“宽度”)。 但是,从长远来看,我认为这是你最好的选择。
根据评论:我使用 Coverity 取得了一些成功。 有点花钱。 有几个好的SO线程可能有更好的选择。
Lots of the various static code analysis tools provide information about inheritance hierarchy. Rather than try and handle it in your code, I would look into a tool that could set up some rules for inheritance hierarchy and fail the build if those rules are not followed. Might cost a little $ and you might have to write a custom rule (I've seen inheritance depth, but not inheritance "breadth" like you want). But, in the long run, I think that's your best bet.
Per comment: I've used Coverity with some success. Bit spendy. There are several good SO threads that may have better options.
您可以使用 GCC-XML,它使用 g++ 编译器前端解析 C++ 源代码并生成 XML 输出。 我希望开发一个工具来解析此输出并检查是否违反规则,这将是相当简单的; 然后可以将其与源代码签入集成。
顺便说一句,让基类了解其后代违反了 开闭原则,这意味着它实际上削弱了面向对象编程的一般用途。 将代码分为基类和子类的主要原因是基类不必知道其子类——这使得诸如在之后交付的插件包之类的事情成为可能安装。
Rather than cluttering the code with assertions, you might be able to use something like GCC-XML, which parses C++ source using the g++ compiler frontend and generates XML output. I expect that it would be reasonably straightforward to develop a tool that parses this output and checks for violations of the rule; this could then be integrated with source code check-in.
BTW, having base classes know about their descendants violates the Open-Closed Principle, meaning that it actually undercuts the usefulness of OO programming in general. The main reason for separating code into base classes and subclasses is so that the base class does not have to know about its subclasses -- this makes possible things like plugin packages delivered after installation.