Restrict inheritance to desired number of classes at compile-time

Question

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 Andre

Answer 1

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.

Answer 2

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.

// create a template class without a body, so all uses of it fail
template < typename D, typename B> class AllowedInheritance;


class Base {};
class Derived; // forward declaration

// but allow Derived, Base by explicit specialization 

template<> class AllowedInheritance< Derived, Base> {};

// privately inherit Derived from that explicit specialization    
class Derived : public Base, private AllowedInheritance<Derived, Base> {};


// Do the same with class Compiler Error
// it has no explicit specialization, so it causes a compiler error
class CompileError: public Base, 
     private AllowedInheritance<CompileError, Base> { };

//error: invalid use of incomplete type 
//‘struct AllowedInheritance<CompileError, Base>’


int main() {

   Base b;
   Derived d;
   return 0;
}

Comment from jon.h:

How does this stop for instance: class Fail : public Base { }; ? \

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 a derived2 : pubic base<derived2>, because base<derived1> and base<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.

Answer 3

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.

Answer 4

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.