Is it possible to forbid deriving from a class at compile time?

Question

I have a value class according to the description in \"C++ Coding Standards\", Item 32. In short, that means it provides value semantics and does not have any virtual method

Answer 1

This solution doesn't work, but I leave it as an example of what not to do.

---

I haven't used C++ for a while now, but as far as I remember, you get what you want by making destructor private.

UPDATE:

On Visual Studio 2005 you'll get either a warning or an error. Check up the following code:

class A
{
public:
    A(){}
private:
    ~A(){}
};

class B : A
{
};

Now,

B b;

will produce an error "error C2248: 'A::~A' : cannot access private member declared in class 'A'"

while

B *b = new B();

will produce warning "warning C4624: 'B' : destructor could not be generated because a base class destructor is inaccessible".

It looks like a half-solutiom, BUT as orsogufo pointed, doing so makes class A unusable. Leaving answers

Answer 2

Take a good look here.
It's really cool but it's a hack.
Wonder for yourself why stdlib doesn't do this with it's own containers.

Answer 3

Even if the question is not marked for C++11, for people who get here it should be mentioned that C++11 supports new contextual identifier final. See wiki page

Answer 4

I would generally achieve this as follows:

// This class is *not* suitable for use as a base class

The comment goes in the header and/or in the documentation. If clients of your class don't follow the instructions on the packet, then in C++ they can expect undefined behavior. Deriving without permission is just a special case of this. They should use composition instead.

Btw, this is slightly misleading: "a base class should have a destructor that is public and virtual or protected and nonvirtual".

That's true for classes which are to be used as bases for runtime polymorphism. But it's not necessary if derived classes are never going to be referenced via pointers to the base class type. It might be reasonable to have a value type which is used only for static polymorphism, for instance with simulated dynamic binding. The confusion is that inheritance can be used for different purposes in C++, requiring different support from the base class. It means that although you don't want dynamic polymorphism with your class, it might nevertheless be fine to create derived classes provided they're used correctly.

Answer 5

If you are willing to only allow the class to be created by a factory method you can have a private constructor.

class underivable {
    underivable() { }
    underivable(const underivable&); // not implemented
    underivable& operator=(const underivable&); // not implemented
public:
    static underivable create() { return underivable(); }
};

Answer 6

Bjarne Stroustrup has written about this here.

---

The relevant bit from the link:

Can I stop people deriving from my class?

Yes, but why do you want to? There are two common answers:

• for efficiency: to avoid my function calls being virtual.
• for safety: to ensure that my class is not used as a base class (for example, to be sure that I can copy objects without fear of slicing)

In my experience, the efficiency reason is usually misplaced fear. In C++, virtual function calls are so fast that their real-world use for a class designed with virtual functions does not to produce measurable run-time overheads compared to alternative solutions using ordinary function calls. Note that the virtual function call mechanism is typically used only when calling through a pointer or a reference. When calling a function directly for a named object, the virtual function class overhead is easily optimized away.

If there is a genuine need for "capping" a class hierarchy to avoid virtual function calls, one might ask why those functions are virtual in the first place. I have seen examples where performance-critical functions had been made virtual for no good reason, just because "that's the way we usually do it".

The other variant of this problem, how to prevent derivation for logical reasons, has a solution. Unfortunately, that solution is not pretty. It relies on the fact that the most derived class in a hierarchy must construct a virtual base. For example:

class Usable;

class Usable_lock {
    friend class Usable;
private:
    Usable_lock() {}
    Usable_lock(const Usable_lock&) {}
};

class Usable : public virtual Usable_lock {
    // ...
public:
    Usable();
    Usable(char*);
    // ...
};

Usable a;

class DD : public Usable { };

DD dd;  // error: DD::DD() cannot access
        // Usable_lock::Usable_lock(): private  member

(from D&E sec 11.4.3).