Why Are Constructors Not Inherited in C#

C# does not inherit the constructor from base class

Constructors are not inherited because we wouldn't be able to properly determine how our derived class objects were instantiated. When all derived classes would use parent's constructors implicitly, in my oppinion it would be a problem because if we forgot to redefine constructor, the object might have been initialized incorrectly. If you would like the derived class constructor to do the same as parent class constructor, call it using base.

Also be aware of the fact that the base class constructor (parameterless) is automatically run if you don't call any other base class constructor taking arguments explicitly. So calling base() is redundant.

Do C# classes inherit constructors?

Constructors have never been inheritable in the entire lifetime of the C# language. That hasn't changed in C# 5.0: at the end of section 1.6.7.1 of the C# 5.0 spec, it still says:

Unlike other members, instance constructors are not inherited, and a class has no instance constructors other than those actually declared in the class. If no instance constructor is supplied for a class, then an empty one with no parameters is automatically provided.

So it still holds true today, and I imagine it will remain so in the foreseeable future.

Why are constructors not inherited in C#?

Sometimes, when subclassing, you want to restrict the conditions required to create an instance of the class.

Let me give you an example. If classes did inherit their superclass constructors, all classes would have the parameterless constructor from Object. Obviously that's not correct.

Can I inherit constructors?

You don't need to create loads of constructors, all with the same code; you create only one, but have the derived classes call the base constructor:

public class Base
{
public Base(Parameter p)
{
Init(p)
}

void Init(Parameter p)
{
// common initialisation code
}
}

public class Derived : Base
{
public Derived(Parameter p) : base(p)
{

}
}

Constructors and Inheritance

Constructors are not inheritable because it might cause weird and unintended behavior. More specifically, if you added a new constructor to a base class, all derived classes get an instance of that constructor. That's a bad thing in some cases, because maybe your base class specifies parameters that don't make sense for your derived classes.

A commonly given example for this is that in many languages, the base class for all objects (commonly called "Object") has a constructor with no parameters. If constructors were inherited, this would mean that all objects have a parameterless constructor, and there's no way to say "I want people who make an instance of this class to provide parameters X, Y and Z, otherwise their code shouldn't compile." For many classes, it's important that certain parameters be defined for their proper function, and making constructors non-heritable is part of the way that class authors can guarantee that some parameters are always defined.

Edit to respond to comments: Ramesh points out that if constructors were inherited as he would like them to be, he could always override base class constructors using privately declared constructors in each derived class. That is certainly true, but there it a logistical problem with this strategy. It requires that writers of derived classes have to watch base classes closely and add a private constructor if they want block inheritance of the base class constructor. Not only is this a lot of work for people writing derived classes, this kind of implicit dependency across classes is exactly the sort of thing that can cause weird behavior.

Ramesh - it's not that what you describe would be impossible to add to a language. In general it's not done because that sort of behavior could confuse people and lead to a lot of extra debugging and code writing.

Quintin Robinson provides some very worthwhile responses to this question in the comments that are definitely worth reading.

C++ Default constructor not inherited with using when move and copy constructors present

Before C++17, the default constructor of the base class won't be inherited via using:

All candidate inherited constructors that aren't the default constructor or the copy/move constructor and whose signatures do not match user-defined constructors in the derived class, are implicitly declared in the derived class. (until C++17)

After C++17 the code works fine.

Before that, the default constructor won't be inherited from the base class, and won't be generated for class B because copy/move constructor are provided.

If no user-declared constructors of any kind are provided for a class type (struct, class, or union), the compiler will always declare a default constructor as an inline public member of its class.

That's why if you comment copy/move constructor out it compiles. You can add the definition explicitly as a pre-C++17 workaround. e.g.

class B : public A {
public:
B(const B&) = default;
B( B&&) = default;

B() = default;
};

The code compiles with gcc8.

Dlang: why are constructors not inherieted?

Java and C# don't inherit constructors either (unless that's changed in the last few years - I don't think C++ allowed it either until c++11), and D follows the same reasoning so you can read more by looking up things about them.

Basically though the reason is that subclasses must have their own unique state - at very least stuff like the vtable even if you don't declare any of your own variables - and thus a unique constructor is required. Otherwise you can have uninitialized members.

And if inheritance went the whole way, since Object has a this(), new AnyClass(); would compile and lead to a lot of invalid objects. (In regular D, if you declare any ctor with arguments, it disables the automatically-generated zero arg one.)

Now, D could in theory do what C++ does and auto-generate other args too... it just doesn't. Probably mostly because that is a relatively new idea in C++ and D's class system is primarily based on Java's older system.

But all that said, let me show you a trick:

this(Args...)(auto ref Args args) { super(args); }

stick that in your subclass and you basically inherit all the parent's constructors in one go. If the super doesn't compile for the given args, neither will this, so it doesn't add random things either. You can overload that with more specific versions if needed too, so it is a reasonable little substitute for a built-in language feature.



Related Topics



Leave a reply



Submit