ValueTypes는 어떻게 Object (ReferenceType)에서 파생되고 여전히 ValueTypes입니까?

ValueTypes는 어떻게 Object (ReferenceType)에서 파생되고 여전히 ValueTypes입니까?

---

C #에서는 구조체가 클래스에서 파생되는 것을 허용하지 않지만 모든 ValueType은 Object에서 파생됩니다. 이 구별은 어디에 있습니까?

CLR은이를 어떻게 처리합니까?

---

C #은 구조체가 클래스에서 파생되는 것을 허용하지 않습니다.

귀하의 진술이 잘못되어 혼란 스럽습니다. C # 에서는 구조체가 클래스에서 파생되는 것을 허용합니다. 모든 구조체는 System.Object에서 파생되는 동일한 클래스 인 System.ValueType에서 파생됩니다. 그리고 모든 열거 형은 System.Enum에서 파생됩니다.

업데이트 : 설명이 필요한 일부 (현재 삭제 된) 댓글에 약간의 혼란이있었습니다. 몇 가지 추가 질문을하겠습니다.

구조체는 기본 유형에서 파생됩니까?

분명히 그렇습니다. 사양의 첫 페이지를 읽으면이를 확인할 수 있습니다.

int 및 double과 같은 기본 형식을 포함한 모든 C # 형식은 단일 루트 개체 형식에서 상속됩니다.

이제 사양이 여기에있는 경우를 과장합니다. 포인터 유형은 객체에서 파생되지 않으며 인터페이스 유형 및 유형 매개 변수 유형에 대한 파생 관계는이 스케치가 나타내는 것보다 더 복잡합니다. 그러나 분명히 모든 구조체 유형이 기본 유형에서 파생되는 경우입니다.

구조체 유형이 기본 유형에서 파생된다는 것을 아는 다른 방법이 있습니까?

확실한. 구조체 유형은 ToString. 기본 유형의 가상 메서드가 아니라면 무엇을 재정의합니까? 따라서 기본 유형이 있어야합니다. 그 기본 유형은 클래스입니다.

내가 선택한 클래스에서 사용자 정의 구조체를 파생시킬 수 있습니까?

분명히 아닙니다. 이것은 구조체가 클래스에서 파생되지 않는다는 것을 의미하지 않습니다 . 구조체는 클래스에서 파생되므로 해당 클래스의 상속 가능한 멤버를 상속합니다. 사실 특정 클래스에서 파생 하려면 구조체가 필요합니다. 에서 파생 하려면 열거 형이 필요하고에서 파생 Enum하려면 구조체가 필요합니다 ValueType. 이것들은 필수 이기 때문에 C # 언어 는 코드에서 파생 관계를 명시하는 것을 금지 합니다.

왜 그것을 금지합니까?

관계가 필수 인 경우 언어 디자이너는 (1) 사용자에게 필요한 주문을 입력하도록 요구하거나, (2) 선택 사항으로 설정하거나, (3) 금지하는 옵션이 있습니다. 각각 장단점이 있으며 C # 언어 디자이너는 각각의 특정 세부 사항에 따라 다르게 선택했습니다.

예를 들어 const 필드는 정적이어야하지만 그렇게하는 것은 첫 번째이고 무의미한 말이고 두 번째는 비 정적 const 필드가 있음을 의미하기 때문에 그렇다고 말하는 것은 금지되어 있습니다. 그러나 오버로드 된 연산자는 개발자가 선택의 여지가 없더라도 정적으로 표시되어야합니다. 개발자가 연산자 오버로드가 인스턴스 메서드라고 믿기에는 너무 쉽습니다. 이것은 사용자가 "정적"이 "가상"도 가능하다는 것을 의미한다고 믿게 될 수 있다는 우려를 무시합니다.

이 경우 사용자가 자신의 구조체가 ValueType에서 파생되었다고 말하도록 요구하는 것은 단순한 지나친 말처럼 보이며 구조체 가 다른 형식에서 파생 될 수 있음을 의미합니다 . 이 두 가지 문제를 모두 제거하기 위해 C #은 코드에서 구조체가 기본 형식에서 파생되었다고 명시 하는 것을 불법 으로 만듭니다 .

마찬가지로 모든 대리자 형식은에서 파생 MulticastDelegate되지만 C #에서는 그렇게 말할 필요가 없습니다 .

이제 우리는 C #의 모든 구조체가 클래스에서 파생 된다는 것을 확인했습니다 .

상속 과 클래스 파생 의 관계는 무엇입니까 ?

많은 사람들이 C #의 상속 관계로 인해 혼란스러워합니다. 상속 관계는 매우 간단합니다. 구조체, 클래스 또는 대리자 형식 D가 클래스 형식 B에서 파생되면 B의 상속 가능한 멤버도 D의 멤버입니다. 간단합니다.

구조체가 ValueType에서 파생된다는 것은 상속과 관련하여 무엇을 의미합니까? 단순히 ValueType의 모든 상속 가능한 멤버는 구조체의 멤버이기도합니다. 이것이 구조체가를 구현하는 방법입니다 ToString. 구조체의 기본 클래스에서 상속됩니다.

유전 가능한 모든 구성원? 분명히 아니다. 개인 구성원은 상속 할 수 있습니까?

예. 기본 클래스의 모든 전용 멤버도 파생 형식의 멤버입니다. 전화 사이트가 회원 의 접근성 도메인 에 있지 않은 경우 해당 회원을 이름으로 부르는 것은 불법 입니다. 회원이 있다고해서 사용할 수있는 것은 아닙니다!

이제 원래 답변을 계속합니다.

---

CLR은이를 어떻게 처리합니까?

아주 좋아요. :-)

값 유형을 값 유형으로 만드는 것은 인스턴스가 value 로 복사된다는 것입니다 . 참조 유형을 참조 유형으로 만드는 것은 해당 인스턴스가 참조 로 복사된다는 것 입니다. 당신은 몇 가지 믿음을 갖고있는 것 같다 상속 값 형식과 참조 형식 사이의 관계가 어떻게 든 특별하고 특이한,하지만 난 그 믿음이 무엇인지 이해하지 않습니다. 상속은 사물이 복사되는 방식과 관련이 없습니다.

이쪽으로 봐. 내가 다음과 같은 사실을 말했다고 가정 해 보겠습니다.

• 두 종류의 상자, 빨간색 상자와 파란색 상자가 있습니다.

• 모든 빨간색 상자는 비어 있습니다.

• O, V 및 E라는 세 개의 특수 파란색 상자가 있습니다.

• O는 상자 안에 없습니다.

• V는 O 안에 있습니다.

• E는 V 안에 있습니다.

• V 안에 다른 파란색 상자가 없습니다.

• E 안에 파란색 상자가 없습니다.

• 모든 빨간색 상자는 V 또는 E에 있습니다.

• O를 제외한 모든 파란색 상자는 파란색 상자 안에 있습니다.

파란색 상자는 참조 유형, 빨간색 상자는 값 유형, O는 System.Object, V는 System.ValueType, E는 System.Enum, "내부"관계는 "에서 파생 됨"입니다.

카드 보드가 많고 인내심이 많으면 쉽게 구현할 수있는 완벽하게 일관되고 간단한 규칙 집합입니다. 상자가 빨간색이든 파란색이든 상자 안에있는 것과는 상관이 없습니다. 현실 세계에서는 파란색 상자 안에 빨간색 상자를 넣는 것이 완벽하게 가능합니다. CLR에서 System.ValueType 또는 System.Enum이면 참조 형식에서 상속되는 값 형식을 만드는 것이 완벽하게 합법적입니다.

따라서 귀하의 질문을 다시 말하겠습니다.

ValueTypes는 어떻게 Object (ReferenceType)에서 파생되고 여전히 ValueTypes입니까?

같이

모든 빨간색 상자 (값 유형)가 파란색 상자 (참조 유형)이고 여전히 빨간색 상자 (값 유형) 인 상자 O (System.Object) 내부 (에서 파생 됨)가 가능할 수 있습니까?

그렇게 표현하면 분명해지기를 바랍니다. 파란색 상자 O 안에있는 상자 V 안에 빨간색 상자를 넣는 것을 막을 수는 없습니다. 왜 있을까요?

---

추가 업데이트 :

Joan의 원래 질문은 그것이 가능하다는 것이 었습니다.값 유형은 참조 유형에서 파생됩니다. 내 원래 대답은 CLR이 완전히 다른 표현을 가진 두 가지 사이에 파생 관계가 있다는 사실을 설명하기 위해 CLR이 사용하는 메커니즘, 즉 참조 된 데이터에 개체 헤더가 있는지 여부를 설명하지 못했습니다. 동기화 블록, 가비지 수집을 위해 자체 스토리지를 소유하는지 여부 등. 이러한 메커니즘은 복잡하고 하나의 답변으로 설명하기에는 너무 복잡합니다. CLR 유형 시스템의 규칙은 예를 들어 유형의 boxed 버전과 unboxed 버전 사이에 강한 구분이없는 C #에서 볼 수있는 다소 단순화 된 특징보다 훨씬 더 복잡합니다. 제네릭의 도입으로 인해 CLR에 많은 복잡성이 추가되었습니다.

---

이것은 모든 형식을 System.Object로 처리 할 수 ​​있도록 CLR에서 유지 관리하는 다소 인위적인 구성입니다.

값 유형은 System.ValueType을 통해 System.Object에서 파생되며 , 여기서 특수 처리가 발생합니다 (예 : CLR은 ValueType에서 파생 된 모든 유형에 대해 boxing / unboxing 등을 처리합니다).

---

작은 수정, C #은 구조체가 클래스뿐만 아니라 모든 것에서 파생되는 것을 허용하지 않습니다. 구조체가 할 수있는 모든 것은 파생과는 매우 다른 인터페이스를 구현하는 것입니다.

이에 대한 가장 좋은 대답은 그것이 ValueType특별 하다고 생각합니다 . 기본적으로 CLR 유형 시스템의 모든 값 유형에 대한 기본 클래스입니다. 이것은 단순히 CLR의 규칙이기 때문에 "CLR이 이것을 어떻게 처리합니까"라고 대답하는 방법을 알기 어렵습니다.

---

귀하의 진술이 잘못되어 혼란 스럽습니다. C #에서는 구조체가 클래스에서 파생되는 것을 허용합니다. 모든 구조체는 동일한 클래스 인 System.ValueType에서 파생됩니다.

그래서 이것을 시도해 봅시다 :

 struct MyStruct :  System.ValueType
 {
 }

이것은 심지어 컴파일되지 않을 것입니다. 컴파일러는 "인터페이스 목록의 'System.ValueType'유형이 인터페이스가 아닙니다."라고 알려줍니다.

구조체 인 Int32를 디 컴파일하면 다음을 찾을 수 있습니다.

public struct Int32 : IComparable, IFormattable, IConvertible {}, System.ValueType에서 파생 된 것은 말할 것도 없습니다. 그러나 개체 브라우저에서는 Int32가 System.ValueType에서 상속한다는 것을 알 수 있습니다.

그래서이 모든 것이 나를 믿게합니다.

대답하는 가장 좋은 방법은 ValueType이 특별하다는 것입니다. 기본적으로 CLR 유형 시스템의 모든 값 유형에 대한 기본 클래스입니다. 이것은 단순히 CLR의 규칙이기 때문에 "CLR이 이것을 어떻게 처리합니까"라고 대답하는 방법을 알기 어렵습니다.

---

박스형 값 유형은 사실상 참조 유형입니다 (하나처럼 걷고 하나처럼 꽥꽥하므로 효과적으로 하나입니다). ValueType은 실제로 값 유형의 기본 유형이 아니라 Object 유형으로 캐스트 할 때 값 유형을 변환 할 수있는 기본 참조 유형이라고 제안합니다. 박스형이 아닌 값 유형 자체는 개체 계층 외부에 있습니다.

---

이론적 해석

모든 답변 중에서 @supercat의 답변은 실제 답변에 가장 가깝습니다. 다른 답변은 실제로 질문에 대한 답변이 아니고, 잘못된 주장을하기 때문에 (예를 들어 값 유형이 어떤 것에서 상속된다는) 질문에 답하기로 결정했습니다.

 

프롤로그

이 답변은 내 리버스 엔지니어링과 CLI 사양을 기반으로합니다.

struct와 classC #을 키워드입니다. CLI에 관한 한 모든 유형 (클래스, 인터페이스, 구조체 등)은 클래스 정의에 의해 정의됩니다.

예를 들어 개체 유형 (C #에서으로 알려짐 class)은 다음과 같이 정의됩니다.

.class MyClass
{
}

 

인터페이스는 interface시맨틱 속성이 있는 클래스 정의에 의해 정의됩니다 .

.class interface MyInterface
{
}

 

값 유형은 어떻습니까?

구조체 System.ValueType가 값 유형 에서 상속 되고 여전히 값 유형일 수있는 이유 는 .. 그렇지 않기 때문입니다.

값 유형은 단순한 데이터 구조입니다. 값 유형은 할 수 없습니다 에서 상속 무엇이든 그들이 할 수없는 인터페이스를 구현합니다. 값 유형은 어떤 유형의 하위 유형도 아니며 유형 정보가 없습니다. 값 유형의 메모리 주소가 주어지면 숨겨진 필드에 유형 정보가있는 참조 유형과 달리 값 유형이 나타내는 것을 식별 할 수 없습니다.

다음 C # 구조체를 상상한다면 :

namespace MyNamespace
{
    struct MyValueType : ICloneable
    {
        public int A;
        public int B;
        public int C;

        public object Clone()
        {
            // body omitted
        }
    }
}

다음은 해당 구조체의 IL 클래스 정의입니다.

.class MyNamespace.MyValueType extends [mscorlib]System.ValueType implements [mscorlib]System.ICloneable
{
    .field public int32 A;
    .field public int32 B;
    .field public int32 C;

    .method public final hidebysig newslot virtual instance object Clone() cil managed
    {
        // body omitted
    }
}

그래서 여기서 무슨 일이 일어나고 있습니까? 명확 연장 System.ValueType대상 / 기준 입력이며, 이는 와 용구 System.ICloneable.

설명은 클래스 정의가 확장 System.ValueType될 때 실제로 두 가지를 정의한다는 것입니다. 값 유형과 값 유형의 해당 박스형 유형입니다. 클래스 정의의 멤버는 값 유형과 해당 박스형 유형 모두에 대한 표현을 정의합니다. 확장하고 구현하는 것은 값 유형이 아니라 해당하는 박스형 유형입니다. extends및 implements키워드 만 박스 유형에 적용.

명확히하기 위해 위의 클래스 정의는 두 가지 작업을 수행합니다.

1. 3 개의 필드 (및 하나의 방법)로 값 유형을 정의합니다. 어떤 것도 상속하지 않으며 어떤 인터페이스도 구현하지 않습니다 (값 유형은 둘 다 수행 할 수 없음).
2. 3 개 필드 (그리고 하나의 인터페이스 방법을 구현), 상속와 개체 유형 (박스형 형)을 정의 System.ValueType하고 구현하는 System.ICloneable인터페이스.

또한 확장하는 모든 클래스 정의 System.ValueType는 sealed키워드 지정 여부에 관계없이 본질적으로 봉인 됩니다.

값 유형은 단순한 구조 일 뿐이므로 상속하거나 구현하지 않으며 다형성을 지원하지 않으므로 나머지 유형 시스템과 함께 사용할 수 없습니다. 이 문제를 해결하기 위해 CLR은 값 형식 외에도 boxed 형식이라고하는 동일한 필드가있는 해당 참조 형식도 정의합니다. 따라서 값 유형 object은를 받는 메서드로 전달할 수 없지만 해당 boxed 유형 은 .

 

이제 C #에서 다음과 같은 메서드를 정의하려면

public static void BlaBla(MyNamespace.MyValueType x),

메소드가 값 유형을 취한다는 것을 알고 있습니다 MyNamespace.MyValueType.

위에서 우리는 structC # 의 키워드에서 나온 클래스 정의가 실제로 값 유형과 객체 유형을 모두 정의한다는 것을 배웠습니다 . 하지만 정의 된 값 유형 만 참조 할 수 있습니다. CLI 사양에 제약 조건 키워드 boxed를 사용하여 유형의 박스형 버전을 참조 할 수 있다고 명시되어 있지만 이 키워드는 존재하지 않습니다 (ECMA-335, II.13.1 참조 값 유형 참조). 그러나 잠시 동안 그렇게한다고 상상해보십시오.

IL에서 유형을 참조 할 때 몇 가지 제약 조건이 지원되며 그중에는 class및 valuetype. 사용하는 경우 valuetype MyNamespace.MyTypeMyNamespace.MyType이라는 값 유형 클래스 정의를 지정합니다. 마찬가지로 class MyNamespace.MyTypeMyNamespace.MyType이라는 객체 유형 클래스 정의를 지정하는 데 사용할 수 있습니다 . 즉, IL에서 동일한 이름을 가진 값 유형 (구조체) 및 객체 유형 (클래스)을 가질 수 있으며 여전히 구별 할 수 있습니다. 이제 boxedCLI 사양에 명시된 키워드가 실제로 구현 된 경우 boxed MyNamespace.MyTypeMyNamespace.MyType이라는 값 유형 클래스 정의의 박스형 유형을 지정할 수 있습니다 .

따라서 .method static void Print(valuetype MyNamespace.MyType test) cil managed라는 값 유형 클래스 정의에 의해 정의 된 값 유형을 취합니다 MyNamespace.MyType.

while .method static void Print(class MyNamespace.MyType test) cil managed이라는 객체 유형 클래스 정의에 의해 정의 된 객체 유형을 사용합니다 MyNamespace.MyType.

마찬가지로 boxed키워드 인 경우 .method static void Print(boxed MyNamespace.MyType test) cil managed라는 클래스 정의에 정의 된 값 유형의 boxed 유형을 사용합니다 MyNamespace.MyType.

그런 다음 다른 개체 형식 같은 박스 타입의 인스턴스와 소요 어떤 방법으로 그것을 주변에 통과 할 수있을 것 System.ValueType, object또는 boxed MyNamespace.MyValueType인수로, 그것은 것, 모든 의도와 목적을 위해, 다른 참조 타입처럼 작동합니다. 값 유형이 아니지만 값 유형의 해당 상자 유형입니다.

 

요약

요약하면 다음과 같은 질문에 답할 수 있습니다.

Value types are not reference types and do not inherit from System.ValueType or any other type, and they cannot implement interfaces. The corresponding boxed types that are also defined do inherit from System.ValueType and can implement interfaces.

A .class definition defines different things depending on circumstance.

• If the interface semantic attribute is specified, the class definition defines an interface.
• If the interface semantic attribute is not specified, and the definition does not extend System.ValueType, the class definition defines an object type (class).
• If the interface semantic attribute is not specified, and the definition does extend System.ValueType, the class definition defines a value type and its corresponding boxed type (struct).

Memory layout

This section assumes a 32-bit process

As already mentioned, value types do not have type information, and thus it's not possible to identify what a value type represents from its memory location. A struct describes a simple data type, and contains just the fields it defines:

public struct MyStruct
{
    public int A;
    public short B;
    public int C;
}

If we imagine that an instance of MyStruct was allocated at address 0x1000, then this is the memory layout:

0x1000: int A;
0x1004: short B;
0x1006: 2 byte padding
0x1008: int C;

Structs default to sequential layout. Fields are aligned on boundaries of their own size. Padding is added to satisfy this.

 

If we define a class in the exact same way, as:

public class MyClass
{
    public int A;
    public short B;
    public int C;
}

Imagining the same address, the memory layout is as follows:

0x1000: Pointer to object header
0x1004: int A;
0x1008: int C;
0x100C: short B;
0x100E: 2 byte padding
0x1010: 4 bytes extra

Classes default to automatic layout, and the JIT compiler will arrange them in the most optimal order. Fields are aligned on boundaries of their own size. Padding is added to satisfy this. I'm not sure why, but every class always has an additional 4 bytes at the end.

Offset 0 contains the address of the object header, which contains type information, the virtual method table, etc. This allows the runtime to identify what the data at an address represents, unlike value types.

Thus, value types do not support inheritance, interfaces nor polymorphism.

Methods

Value types do not have virtual method tables, and thus do not support polymorphism. However, their corresponding boxed type does.

When you have an instance of a struct and attempt to call a virtual method like ToString() defined on System.Object, the runtime has to box the struct.

MyStruct myStruct = new MyStruct();
Console.WriteLine(myStruct.ToString()); // ToString() call causes boxing of MyStruct.

However, if the struct overrides ToString() then the call will be statically bound and the runtime will call MyStruct.ToString() without boxing and without looking in any virtual method tables (structs don't have any). For this reason, it's also able to inline the ToString() call.

If the struct overrides ToString() and is boxed, then the call will be resolved using the virtual method table.

System.ValueType myStruct = new MyStruct(); // Creates a new instance of the boxed type of MyStruct.
Console.WriteLine(myStruct.ToString()); // ToString() is now called through the virtual method table.

However, remember that ToString() is defined in the struct, and thus operates on the struct value, so it expects a value type. The boxed type, like any other class, has an object header. If the ToString() method defined on the struct was called directly with the boxed type in the this pointer, when trying to access field A in MyStruct, it would access offset 0, which in the boxed type would be the object header pointer. So the boxed type has a hidden method that does the actual overriding of ToString(). This hidden method unboxes (address calculation only, like the unbox IL instruction) the boxed type then statically calls the ToString() defined on the struct.

Likewise, the boxed type has a hidden method for each implemented interface method that does the same unboxing then statically calls the method defined in the struct.

 

CLI specification

Boxing

I.8.2.4 For every value type, the CTS defines a corresponding reference type called the boxed type. The reverse is not true: In general, reference types do not have a corresponding value type. The representation of a value of a boxed type (a boxed value) is a location where a value of the value type can be stored. A boxed type is an object type and a boxed value is an object.

Defining value types

I.8.9.7 Not all types defined by a class definition are object types (see §I.8.2.3); in particular, value types are not object types, but they are defined using a class definition. A class definition for a value type defines both the (unboxed) value type and the associated boxed type (see §I.8.2.4). The members of the class definition define the representation of both.

II.10.1.3 The type semantic attributes specify whether an interface, class, or value type shall be defined. The interface attribute specifies an interface. If this attribute is not present and the definition extends (directly or indirectly) System.ValueType, and the definition is not for System.Enum, a value type shall be defined (§II.13). Otherwise, a class shall be defined (§II.11).

Value types do not inherit

I.8.9.10 In their unboxed form value types do not inherit from any type. Boxed value types shall inherit directly from System.ValueType unless they are enumerations, in which case, they shall inherit from System.Enum. Boxed value types shall be sealed.

II.13 Unboxed value types are not considered subtypes of another type and it is not valid to use the isinst instruction (see Partition III) on unboxed value types. The isinst instruction can be used for boxed value types, however.

I.8.9.10 A value type does not inherit; rather the base type specified in the class definition defines the base type of the boxed type.

Value types do not implement interfaces

I.8.9.7 Value types do not support interface contracts, but their associated boxed types do.

II.13 Value types shall implement zero or more interfaces, but this has meaning only in their boxed form (§II.13.3).

I.8.2.4 Interfaces and inheritance are defined only on reference types. Thus, while a value type definition (§I.8.9.7) can specify both interfaces that shall be implemented by the value type and the class (System.ValueType or System.Enum) from which it inherits, these apply only to boxed values.

The non-existent boxed keyword

II.13.1 The unboxed form of a value type shall be referred to by using the valuetype keyword followed by a type reference. The boxed form of a value type shall be referred to by using the boxed keyword followed by a type reference.

Note: The specification is wrong here, there is no boxed keyword.

Epilogue

I think part of the confusion of how value types seem to inherit, stems from the fact that C# uses casting syntax to perform boxing and unboxing, which makes it seem like you're performing casts, which is not really the case (although, the CLR will throw an InvalidCastException if attempting to unbox the wrong type). (object)myStruct in C# creates a new instance of the boxed type of the value type; it does not perform any casts. Likewise, (MyStruct)obj in C# unboxes a boxed type, copying the value part out; it does not perform any casts.

참고URL : https://stackoverflow.com/questions/1682231/how-do-valuetypes-derive-from-object-referencetype-and-still-be-valuetypes