问题
Scenario is very rare, but quite simple: you define a generic class, then create a nested class which inherits from outer class and define a associative field (of self type) within nested. Code snippet is simpler, than description:
class Outer<T>
{
class Inner : Outer<Inner>
{
Inner field;
}
}
after decompilation of IL, C# code look like this:
internal class Outer<T>
{
private class Inner : Outer<Outer<T>.Inner>
{
private Outer<Outer<T>.Inner>.Inner field;
}
}
This seems to be fair enough, but when you change the type declaration of the field, things become trickier. So when I change the field declaration to
Inner.Inner field;
After decompilation this field will looks like this:
private Outer<Outer<Outer<T>.Inner>.Inner>.Inner field;
I understand, that class 'nestedness' and inheritance don't quite get along with each other, but why do we observe such behavior? Is the Inner.Inner type declaration has changed the type at all? Are Inner.Inner and Inner types differ in some way in this context?
When things become very tricky
You can see the decompiled source code for the class below. It's really huge and has total length of 12159 symbols.
class X<A, B, C>
{
class Y : X<Y, Y, Y>
{
Y.Y.Y.Y.Y.Y y;
}
}
Finally, this class:
class X<A, B, C, D, E>
{
class Y : X<Y, Y, Y, Y, Y>
{
Y.Y.Y.Y.Y.Y.Y.Y.Y y;
}
}
results in 27.9 MB (29,302,272 bytes) assembly and Total build time: 00:43.619
Tools used
Compilation is done under C# 5 and C# 4 compilers. Decompilation is done by dotPeek. Build configurations: Release and Debug
回答1:
The core of your question is why Inner.Inner is a different type than Inner. Once you understand that, your observations about compile time and generated IL code size follow easily.
The first thing to note is that when you have this declaration
public class X<T>
{
public class Y { }
}
There are infinitely many types associated with the name Y. There is one for each generic type argument T, so X<int>.Y is different than X<object>.Y, and, important for later, X<X<T>>.Y is a different type than X<T>.Y for all T's. You can test this for various types T.
The next thing to note is that in
public class A
{
public class B : A { }
}
There are infinitely many ways to refer to nested type B. One is A.B, another is A.B.B, and so on. The statement typeof(A.B) == typeof(A.B.B) returns true.
When you combine these two, the way you have done, something interesting happens. The type Outer<T>.Inner is not the same type as Outer<T>.Inner.Inner. Outer<T>.Inner is a subclass of Outer<Outer<T>.Inner> while Outer<T>.Inner.Inner is a subclass of Outer<Outer<Outer<T>.Inner>.Inner>, which we established before as being different from Outer<T>.Inner. So Outer<T>.Inner.Inner and Outer<T>.Inner are referring to different types.
When generating IL, the compiler always uses fully qualified names for types. You have cleverly found a way to refer to types with names whose lengths that grow at exponential rates. That is why as you increase the generic arity of Outer or add additional levels .Y to the field field in Inner the output IL size and compile time grow so quickly.
回答2:
This is not an answer!
There are many aspects of your question. A little one is: If a type contains (because of inheritance, not allowed otherwise) a nested type with the same name as the type itself, and if that name is used inside the type, what does the name refer to?
It's hard to express in words, but here's the example I have in mind:
namespace N
{
class Mammal
{
// contains nested type of an unfortunate name
internal interface Giraffe
{
}
}
class Giraffe : Mammal
{
Giraffe g; // what's the fully qualified name of the type of g?
}
}
Note: This is easy! No generics! No problem with a class inheriting its own containing class.
The question here is, what is the type of g? Is it N.Giraffe (a class), or is it N.Giraffe.Giraffe (an interface)? The correct answer is the latter. Because to find a meaning for the name Giraffe, one first searches the members of the current type (in this case one finds the interface). Only if no match is found there, one proceeds to the members of the current namespace (where the current type would be found).
回答3:
Inheriting from a generic parameterized with the current type is often called Curiously recurring template pattern and is discouraged by Eric Lippert, previously on the C# compiler team.
In your case, the nested class Outer<A>.Inner is defined as inheriting from Outer<Inner>. That means the nested class contains, through inheritance, a definition of a nested class. This yields an infinite definition of nested classes: Outer<A>.Inner.Inner.Inner...
Now, in your original definition
class Inner : Outer<Inner>
{
Inner field;
}
the field is declared as type Inner which in this scope refers to the current type being defined. When you changed it to Inner.Inner, the first Inner referred to the current type being defined and the second .Inner referred to the nested class obtained through inheritance.
As an example, let's expand the definition of the Inner class to include what is coming from the inheritance (and renaming to make things a little clearer):
//original
class Outer<A>
{
class Inner1 //: Outer<Inner1>
{
Inner1 field;
//from inheritance
class Inner2 : Outer<Inner1.Inner2>
{
Inner2 field;
}
}
}
//modified for Inner.Inner
class Outer<A>
{
class Inner1 //: Outer<Inner1>
{
Inner1.Inner2 field;
//from inheritance
class Inner2 : Outer<Inner1.Inner2>
{
Inner2.Inner3 field;
}
}
}
So back to your questions:
Why do we observe such behavior? Is the Inner.Inner type declaration has changed the type at all? Are Inner.Inner and Inner types differ in some way in this context?
You changed the type definition of class Inner so that its field is of a different type. An instance of Outer<A>.Inner would possibly (I have not verified) be castable to the other Inner type but they are 2 type definitions.
来源：https://stackoverflow.com/questions/14177225/why-does-field-declaration-with-duplicated-nested-type-in-generic-class-results