Why don't structs support inheritance?

Question

I know that structs in .NET do not support inheritance, but its not exactly clear why they are limited in this way.

What technical reason prevents structs from inheriting from other structs?

Solution 1

The reason value types can't support inheritance is because of arrays.

The problem is that, for performance and GC reasons, arrays of value types are stored "inline". For example, given new FooType[10] {...}, if FooType is a reference type, 11 objects will be created on the managed heap (one for the array, and 10 for each type instance). If FooType is instead a value type, only one instance will be created on the managed heap -- for the array itself (as each array value will be stored "inline" with the array).

Now, suppose we had inheritance with value types. When combined with the above "inline storage" behavior of arrays, Bad Things happen, as can be seen in C++.

Consider this pseudo-C# code:

struct Base
{
    public int A;
}

struct Derived : Base
{
    public int B;
}

void Square(Base[] values)
{
  for (int i = 0; i < values.Length; ++i)
      values [i].A *= 2;
}

Derived[] v = new Derived[2];
Square (v);

By normal conversion rules, a Derived[] is convertible to a Base[] (for better or worse), so if you s/struct/class/g for the above example, it'll compile and run as expected, with no problems. But if Base and Derived are value types, and arrays store values inline, then we have a problem.

We have a problem because Square() doesn't know anything about Derived, it'll use only pointer arithmetic to access each element of the array, incrementing by a constant amount (sizeof(A)). The assembly would be vaguely like:

for (int i = 0; i < values.Length; ++i)
{
    A* value = (A*) (((char*) values) + i * sizeof(A));
    value->A *= 2;
}

(Yes, that's abominable assembly, but the point is that we'll increment through the array at known compile-time constants, without any knowledge that a derived type is being used.)

So, if this actually happened, we'd have memory corruption issues. Specifically, within Square(), values[1].A*=2 would actually be modifying values[0].B!

Try to debug THAT!

Solution 2

Imagine structs supported inheritance. Then declaring:

BaseStruct a;
InheritedStruct b; //inherits from BaseStruct, added fields, etc.

a = b; //?? expand size during assignment?

would mean struct variables don't have fixed size, and that is why we have reference types.

Even better, consider this:

BaseStruct[] baseArray = new BaseStruct[1000];

baseArray[500] = new InheritedStruct(); //?? morph/resize the array?

Solution 3

Structs do not use references (unless they are boxed, but you should try to avoid that) thus polymorphism isn't meaningful since there is no indirection via a reference pointer. Objects normally live on the heap and are referenced via reference pointers, but structs are allocated on the stack (unless they are boxed) or are allocated "inside" the memory occupied by a reference type on the heap.

Solution 4

Class like inheritance is not possible, as a struct is laid directly on the stack. An inheriting struct would be bigger then it parent, but the JIT doesn't know so, and tries to put too much on too less space. Sounds a little unclear, let's write a example:

struct A {
    int property;
} // sizeof A == sizeof int

struct B : A {
    int childproperty;
} // sizeof B == sizeof int * 2

If this would be possible, it would crash on the following snippet:

void DoSomething(A arg){};

...

B b;
DoSomething(b);

Space is allocated for the sizeof A, not for the sizeof B.

Solution 5

Here's what the docs say:

Structs are particularly useful for small data structures that have value semantics. Complex numbers, points in a coordinate system, or key-value pairs in a dictionary are all good examples of structs. Key to these data structures is that they have few data members, that they do not require use of inheritance or referential identity, and that they can be conveniently implemented using value semantics where assignment copies the value instead of the reference.

Basically, they're supposed to hold simple data and therefore do not have "extra features" such as inheritance. It would probably be technically possible for them to support some limited kind of inheritance (not polymorphism, due to them being on the stack), but I believe it is also a design choice to not support inheritance (as many other things in the .NET languages are.)

On the other hand, I agree with the benefits of inheritance, and I think we all have hit the point where we want our struct to inherit from another, and realize that it's not possible. But at that point, the data structure is probably so advanced that it should be a class anyway.

View more solutions

Comments

[Dykam]

That is not the reason why there is no inheritance.

[rmeador]

one does not need to use polymorphism to take advantage of inheritance

[Muhammad Huzaifa]

I believe the inheritance being talked about here is not being able to use two structs where one inherits from the other interchangeably, but re-using and adding to the implementation of one struct to another (i.e. creating a Point3D from a Point2D; you would not be able to use a Point3D instead of a Point2D, but you wouldn't have to reimplement the Point3D entirely from scratch.) That's how I interpreted it anyways...

[rmeador]

C++ handles this case just fine, IIRC. The instance of B is sliced to fit in the size of an A. If it's a pure data type, as .NET structs are, then nothing bad will happen. You do run into a bit of a problem with a method that returns an A and you're storing that return value in a B, but that shouldn't be allowed. In short, the .NET designers could have dealt with this if they wanted to, but they didn't for some reason.

[jonp]

For your DoSomething(), there isn't likely to be a problem as (assuming C++ semantics) 'b' would be "sliced" to create an A instance. The problem is with <i>arrays</i>. Consider your existing A and B structs, and a <c>DoSomething(A[] arg){arg[1].property = 1;}</c> method. Since arrays of value types store the values "inline", DoSomething(actual = new B[2]{}) will cause actual[0].childproperty to be set, not actual[1].property. This is bad.

[Muhammad Huzaifa]

In short: it could support inheritance without polymorphism. It doesn't. I believe it's a design choice to help a person choose class over struct when appropriate.

[John Saunders]

So, you'd have how many different types of inheritance in .NET?

[rmeador]

@John: I wasn't asserting it was, and I don't think @jonp was either. We were merely mentioning that this problem is old and has been solved, so the .NET designers chose not to support it for some reason other than technical infeasibility.

[jonp]

It should be noted that the "arrays of derived types" issue isn't new to C++; see parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.4 (Arrays in C++ are evil! ;-)

[jonp]

@John: the solution to "arrays of derived types and base types don't mix" problem is, as usual, Don't Do That. Which is why arrays in C++ are evil (more easily permits memory corruption), and why .NET doesn't support inheritance with value types (compiler and JIT ensure that it can't happen).

[Henk Holterman]

The compiler knows what's there. Referencing C++ this cannot be the answer.

[Kenan E. K.]

Polymorphism does exist in structs, just consider the difference between calling ToString() when you implement it on a custom struct or when a custom implementation of ToString() does not exist.

[John Saunders]

That's because they all derive from System.Object. It's more the polymorphism of the System.Object type than of structs.

[jonp]

C++ answered this by introducing the concept of 'slicing', so that's a solvable problem. So, why shouldn't struct inheritance be supported?

[Dykam]

C++ has solved that, read this answer for the real problem: stackoverflow.com/questions/1222935/…

[Niki]

I can think of at least two sensible ways for the compiler to handle that that would never lead to a crash. Of course I can think of lots of ways to implement it that will crash, but why would you want to imlpement it that way?

[Kenan E. K.]

Consider arrays of inheritable structs, and remember that C# is a (memory)managed language. Slicing or any similar option would wreak havoc on the fundamentals of the CLR.

[Niki]

The sensible solution to that problem would be to disallow the cast form Base[] to Detived[]. Just like casting from short[] to int[] is forbidden, although casting from short to int is possible.

[Juliet]

@jonp: Solvable, yes. Desirable? Here's a thought experiment: imagine if you have a base class Vector2D(x, y) and derived class Vector3D(x, y, z). Both classes have a Magnitude property which calculates sqrt(x^2 + y^2) and sqrt(x^2 + y^2 + z^2) respectively. If you write 'Vector3D a = Vector3D(5, 10, 15); Vector2D b = a;', what should 'a.Magnitude == b.Magnitude' return? If we then write 'a = (Vector3D)b', does a.Magnitude have the same value before the assignment as it does after? The .NET designers probably said to themselves, "no, we'll have none of that".

[Dan Diplo]

Just because a problem can be solved, doesn't mean it should be solved. Sometimes it's just best to avoid situations where the problem arises.

[Juliet]

+answer: the problem with inheritance didn't click with me until you put it in terms of arrays. Another user stated that this problem could be mitigated by "slicing" structs to the appropriate size, but I see slicing as being the cause of more problems than it solves.

[jonp]

Yes, but that "makes sense" because array conversions are for implicit conversions, not explicit conversions. short to int is possible, but requires a cast, so it's sensible that short[] can't be converted to int[] (short of conversion code, like 'a.Select(x => (int) x).ToArray()'). If the runtime disallowed the cast from Base to Derived, it would be a "wart", as that IS allowed for reference types. So we have two different "warts" possible -- forbid struct inheritance or forbid conversions of arrays-of-derived to arrays-of-base.

[jonp]

At least by preventing struct inheritance we have a separate keyword and can more easily say "structs are special", as opposed to having a "random" limitation in something that works for one set of things (classes) but not for another (structs). I imagine that the struct limitation is far easier to explain ("they're different!").

[Niki]

@jonp: short to int doesn't require a cast. It's an implicit conversion.

[binarydreams]

You're right, that is terrible assembly. In fact, I think you'd need a C compiler to compile it ;)

[Cecil Has a Name]

Where did you infer C++ from? I'd go with saying in-place because that's what matches the behaviour the best, the stack is an implementation detail, to quote an MSDN blog article.

[Henk Holterman]

Yes, mentioning C++ was bad, just my train of thought. But aside from the question if runtime info is needed, why shouldn't structs have an 'object header' ? The compiler can mash them up anyway it likes. It could even hide a header on a [Structlayout] struct.

[user38001]

Almost. Nobody else mentioned the slicing problem in reference to the stack, only in reference to arrays. And nobody else mentioned the available solutions.

[Cecil Has a Name]

Because structs are value types, it is not necessary with an object header because the run-time always copies the content as for other value types (a constraint). It wouldn't make sense with a header, because that's what reference-type classes are for :P

[John]

need to change the name of the function from 'square' to 'double'

[Marc Gravell]

Everything that you've mentioned here in the context of arrays would apply equally to a struct on the stack; arrays are just a single example of why this can't work.

[supercat]

All value types in .net are zero-filled on creastion, regardless of their type or what fields they contain. Adding something like a vtable pointer to a struct would require a means of initializing types with non-zero default values. Such a feature might be useful for a variety of purposes, and implementing such a thing for most cases might not be too hard, but nothing close exists in .net.

[supercat]

The problem with arrays would apply just as well even if arrays did not support covariance, since one should theoretically able to able to store a Derived into a Base and have the system still know it's a Derived. Even if derived types had to be the same size as base types (perhaps by having base types predeclare the maximum size of a derived struct) the requirement that the system know whether an object is a base or derived type would still be a problem. If I had my druthers, though, structs would support a couple forms of inheritance-like behavior: ...

[supercat]

...(1) Allow types to be declared as extending or aliasing other types (including structs); an extension or alias type would be stored at runtime as the base type, but could have added properties or functions (somewhat like extension functioins, but with clearer scoping rules); (2) Allow structs to have defined inheritance relations which would not apply to instances, but would apply to generic types, so a ColoredPoint which inherited Point and included color could be passed to a routine MovePoint<T>(ref T pt, int dx, int dy) where T:Point. For the latter to be most helpful, the...

[supercat]

...system would also have to provide a means of performing a "byref cast if possible" (so that if a function was called with a T that was some particular derivative of Point, its extra fields could be used). Note that composition could do some of what could be done with generics like those above, provided that the enclosed things were stored as exposed public fields, but some people dislike those. I doubt any such features will be added to .net, since some people like to disparage value types rather than try to fix their shortcomings.

[supercat]

@kek444: Having struct Foo inherit Bar should not allow a Foo to be assigned to a Bar, but declaring a struct that way could allow a couple of useful effects: (1) Create a specially-named member of type Bar as the first item in Foo, and have Foo include member names that alias to those members in Bar, allowing code which had used Bar to be adapted to use a Foo instead, without having to replace all references to thing.BarMember with thing.theBar.BarMember, and retaining the ability to read and write all of Bar's fields as a group; ...

[supercat]

(2) It could be possible to have a generic member use type T:Bar and use Bar's members on T. Without such ability, the only way to allow things like Interlocked updates to Bar's members would be to have interface members which use such members mutate this. While that could certainly be done, the semantics of structs with mutating interfaces are very quirky, especially since there's no way to have a struct satisfy an IFoo constraint without it also allowing a representation-changing cast to an IFoo, even if such casts would almost never work as desired.

[supercat]

Polymorphism could be meaningful with structures used as generic type parameters. Polymorphism works with structs that implement interfaces; the biggest problem with interfaces is that they can't expose byrefs to struct fields. Otherwise, the biggest thing I think would be helpful as far as "inheriting" structs would be a means of having a type (struct or class) Foo that has a field of structure type Bar be able to regard Bar's members as its own, so that a Point3d class could e.g. encapsulate a Point2d xy but refer to the X of that field as either xy.X or X.

[David Klempfner]

@user38001 "Structs are allocated on the stack" - unless they are instance fields in which case they're allocated on the heap.

[v.oddou]

in C# all identifiers are references, so there is no excuse for the compiler not to box b, and hold a reference to b in a, with a warning from a linter maybe.

[Paul Childs]

Using c++ is not a good example as classes and stucts are only different in terms of default access. If your logic was valid then one could equally say c# classes don't support inheritance.

[ToolmakerSteve]

@KenanE.K. - true. A better way of describing the limitation is that (unboxed) structs require polymorphism to be resolved at compile time. The lack of a reference pointer makes it impossible to resolve dynamically.

[ToolmakerSteve]

@Blixt - no, it couldn't support inheritance, because structs deliberately lack the necessary method reference pointer. The design criteria is that a struct use as little memory as possible. In particular, when embedded in another entity, or in an array. So it only "could support inheritance" by sacrificing the only reason that structs exist at all!

[ToolmakerSteve]

"the reason structs cannot be inherited is because they live on the stack is the right one" - no, it isn't the reason.

[PD1978US]

A variable of a ref type will contain a reference to an object in the heap. A variable of a value type will contain the value of the data itself. The size of the data must be known at compile-time. This includes local variables, which includes parameters, which all live in the stack. Thinking about it the size of all object fields must be known during object allocation as well. So, I accept the stack a special case of a general reason, but it is still a reason, though.

[Muhammad Huzaifa]

@ToolmakerSteve You can do simple inheritance with stack allocated types. Have a look at embedded types in Go. I agree it's not possible to do polymorphic inheritance which you're talking about (and this is also mentioned above).

[ToolmakerSteve]

When you put it that way, I agree. I was thinking about the other half of inheritance, where it is impossible to work with the data because the data doesn’t include a pointer to a class ref, so it is not knowable which subclass (sub-struct?) the data is from. Its just a meaningless sequence of bits.

[ToolmakerSteve]

@Blixt - ok, I misunderstood your previous comments. Do you agree that the fundamental issue isn't whether something is put on the stack or not, it is whether the type is knowable at compile time. If it is, then I agree - that could easily be supported, if language designers chose to. Its an implementation convenience (automatic method and field promotion), and all parties know at compile time which methods to call, and the size of the data. Does that match your view of it?