혹평 VCL: 비침 없는 타입

많은 사람들의 비판에 부딪혔지만 결국 버텼다.이 시리즈에서는 주로 평소 VCL을 사용하면서 델파이가 잘 처리하지 못한 점을 염두에 두고 있다.간혹 자신의 견해를 제기할 수 있어 화제로 삼을 수 있다.더 중요한 것은 우리가 이것을 빌려 몇 가지 사상을 배울 수 있다는 것이다.
Delphi는 다른 언어에 비해 매우 뚜렷한 특징을 가지고 있는데 그것이 바로 유인용이다.일반적인 주장은 다음과 같습니다.

  
  
  
  

   
   
   
   
TComponentClass = class of TComponent; 
  
  
  
  

이 간단한 성명을 얕보지 마라. 그는 너로 하여금 클래스의 VMT에 직접 방문하게 할 수 있다.리비 씨의'인사이드 VCL'에서 델피에 대해 이야기했다.NET 때도 이에 대해 특별한 설명이 있었다.대상과 대상의 차이는 일정한 의미에서 그것이 가리키는 VMT의 차이에 있다.
VCL에서는 각 클래스의 VMT에 고유한 주소 공간이 있습니다.따라서 VCL은 두 종류의 유형이 일치하는지 판단할 때 주소가 같은 방식을 간단하게 사용한다.이 중에서 가장 자주 사용하는 것은 Is 조작부호의 실현이다.모든 부모 유형을 훑어보고 일치 여부를 판단합니다.
VMT와 유사하게 Delphi의 일부 기본 유형도 자신의 유형 주소 공간이 있습니다.이러한 유형의 저장이 C#에 있으면 유형 반사라고 할 수 있습니다.그러나 델피에서는 퍼블릭 속성을 실현하기 위한 유형 검사라고 할 수 있다.그들의 유형 검사도 마찬가지로 주소 공간을 이용하여 판단한다.예를 들어, 속성이 Boolean인지 여부를 판단합니다.너는 TypInfo 단원에서 상응하는 실현 코드를 찾을 수 있다.
나는 TObjectGrid를 실현할 때 RTTI 정보를 사용하여 대상의 속성 값을 얻었다.한 가지 요구 사항은 체크 셀에 대응하는 속성이 Boolean인지 판단하는 것입니다. 만약 그렇다면 체크박스 모드를 사용하여 편집하십시오.최초의 실현 코드는 다음과 같다.

  
  
  
  

   
   
   
   
if GetTypeData(PropInfo^.PropType^)^.BaseType^ = TypeInfo(Boolean) then ... 
  
  
  
  

이 코드는 언젠가 우리의 업무 데이터 대상이 Dll에서 되돌아올 때까지 정상적으로 실행되었다.이 판단은 단번에 실효가 났다!
이 문제를 이해할 수 있는 사람은 이 유형의 판단이 주소 공간을 사용하기 때문에 일어난 것임을 알 수 있을 것이다.Exe와 Dll에는 고유한 유형의 주소 공간이 있습니다.Dll이 Exe에 로드되면 Dll의 유형 주소 공간이 재배치되므로 Dll의 Boolean 유형 주소와 Exe의 유형 주소가 없을 때의 주소 공간입니다.나는 나중에 유형이 일치하는지 아닌지를 판단하기 위해 명칭을 사용했다.
만약 Dll의 인터페이스에서 Tstrings 형식의 속성을 정의한다면, Exe에서 Tstrings 클래스의 Assign 기능을 사용할 때 이외의 일이 발생할 수 있습니다.Tstrings가 Assign 기능을 구현할 때 다음과 같은 판단이 있기 때문입니다.

  
  
  
  

   
   
   
   
if Source is TStrings then 
  
  
  
  

위의 설명을 통해 이 코드의 판단은false로 되돌아왔고 그 아래의 값 부여 조작은 반드시 실행되지 않을 것이다.물론 Is라면 As 조작부호도 비슷한 표현을 할 수 있을 거라고 생각할 수 있을 것이다.As가 Is로 판단했으니까.
내가 위에서 반나절을 말했는데, 사실 Exe와 Dll 사이의 같은 유형은 완전히 동일시할 수 없다는 것이다.특히 인터페이스 사이로 전달될 때당연하죠. 유형 전달은 비기본 유형을 허용하지 않는다고 약속할 수 있습니다.하지만 기초를 전달하는 유혹이 적지 않아 처리가 많이 줄어들었다.
그러나 L슈퍼맨이 언급한 바와 같이 델피의 Bpl에는 이런 문제가 없다. 왜냐하면 그들의 유형은 모두 공유되기 때문이다.
VCL에 있는 이 약점을 겨냥해서 좋은 디자인은 찾기가 쉽지 않다고 해야 하는데..NET의 Dll은 유형 공유를 실현했고 이 Delphi의 Bpl 사상은 일치했다.생각해보면 Dll의 규범이 대상 언어보다 일찍 유행한 원인일 것이다.이전 Dll 정의에서는 복잡한 유형의 인터페이스 전송을 고려하지 않았습니다.따라서 델피는 위에서 이루어지면 많은 문제에 부딪힐 수 있다.가장 큰 것은 언어와 버전의 문제다.

서로 다른 언어로 이루어진 Dll은 어떻게 유형의 상통을 보장합니까?

서로 다른 버전의 VCL 유형은 어떻게 일치합니까?

이 두 가지 문제를 해결하면 유형은 응용 프로그램의 경계를 자유롭게 통과할 수 있다.나는 Delphi가 이 결함을 다시 설계하기를 바라는 것이 아니다.그러나 안타깝게도 델피는 자신의 Bpl을 널리 알리지 못했다.마치.NET가 Dll의 사양을 수정한 것과 같습니다.델피의 Bpl도 Dll로 바뀌면 허허, 결과가 어떻게 될지 모르겠다.