GRF 파일 저장 문제

이번에 DSPack의 버그를 하나 잡는 과정에서 아리송한 부분이 발견되었는데요, 그 과정은 이렇습니다. 

그동안 이상하게도 DSPack의 데모 필터소스는 C++의 원본을 거의 완벽하게 변환한 것임에도 불구하고 GraphEdit상

에서 사용되어질때 GRF파일로 저장 되지 않는다는 미스테리를 안고 있었습니다. 언젠가 시간이 나면 한번 풀어보고

 

자 하였는데 이번 기회에 결국 해결을 보게 되었습니다.

 

 

결론부터 말씀드리자면 GraphEdit에서 DSPack 의 데모필터를 GRF 파일로 저장할때 IPersist 라는 인터페이스를 사

 

용하게 되는데요, 이 인터페이스가 DSPack의 BaseClass.pas에 분명히 구현되어 있음에도 불구하고 자꾸만 Graph

 

Edit가 '인터페이스를 지원하지 않습니다'라는 오류 메시지를 내보내는 것이었습니다. 그래서 계속 추적해 들어가보니

 

여러가지 원인이 있었지만 그중에 핵심적인 부분인 GetInterface라는 함수를 델파이의 System.pas에서 굉장히 다른

 

내부구조로 변환되어 있음을 발견하게 되었습니다. 여러분도 살펴보시면 아시겠지만 VC++의 Getinterface의 내부구

 

조는 단 10줄을 넘지 않습니다. 그런데 델파이의 GetInterface의 구조는 상당히 여러복층 구조를 가지고 있었습니다.

 

하지만 정작 문제는 이러한 구조가 아니라 결과값이 다르다는데 있었습니다. 예를 들어서 다음과 같은 인터페이스 상

속이 있다고 하고, 그 인터페이스의 가장 아랫자식의 인터페이스를 COM 클래스로 선언해보겠습니다.  

  

           A -> B -> C -> D


     TMyCom = class(TObject, D)
      private
      public 
       Function ... 인터페이스 멤버함수.
        .
        .
        .
      end;



위와같이 선언되어 있는 클래스에서 만일 VC++의 GetInterface로 TMyCom 객체에서 GetInterface를 사용하여 B라는
 
인터페이스를 얻어올 수가 있습니다. 왜냐하면 D의 부모이기 때문입니다. 그런데 이상하게도 델파이의 GetInterface

함수를 사용하면 위의 TMyCom객체에서 오로지 D 인터페이스 밖에 얻을 수가 없습니다. 델파이에서 GetInterface

를 사용하여 B 인터페이스를 얻고자 한다면 아래와 같이 선언해 주어야 합니다.  




     TMyCom = class(TObject, A, B, C,  D)
      private
      public 
        Function ... 인터페이스 멤버함수.
        .
        .
        .
      end;



즉, 위와같이 상속되어지는 모든 인터페이스를 다중상속처럼 열거해 놓아야 한다는 것이죠. 이게 상식적으로 조금 이

상합니다. 물론 D 하나만 선언해 놓아도 A, B, C  인터페이스의 멤버함수는 모두 구현되어져야 하는 것이겠지만, 그렇

다고 하더라도 모든 부모를 위와같은 방식으로 다중상속처럼 열거해야만이 GetInterface함수에서 얻어질 수가 있다니

조금 의외라는 생각을 지울수가 없습니다.


아마도 그래서 DSPack을 만드신 분이나, 처음에 DirectShow.pas나 BaseClass.pas를 만드셨던 모든 분들이 약간

은 헷갈려했지 않나 싶습니다. 만일 그분들이 헷갈리지 않으셨다면 BaseClass.pas에서 사용된 GetInterface함수는

내부에서 재정의 되어야 했을 터입니다. 저처럼 VC++와 델파이의 GetInterface의 작동이 동일할 것이라는 가정하에

만드신 것으로 생각됩니다.


이렇게 보았을때 대체 버그의 원인은 델파이의 GetInterface 함수에 있지 않나 싶습니다. 물론 VC++의 GetInterface

함수를 델파이로 옮기는 것이 생각처럼 쉬운 문제가 아니라는 것은 충분히 이해하고도 남습니다. 만일 이것이 델파이

의 System.Pas에 선언되어있지 않다면(그럴리는 없었겠지만) 아마도 델파이 진영에서의 중요한 화두로 회자되지 않

았을까 싶습니다. 아무튼 이 결과를 보았을때 지금도 GetInterface의 작동구조가 다시한번 논의되어야 하지 않을까 싶

기도 합니다.


이번에 버그잡느라고 몇일밤을 꼬박 새었습니다. 너무 어이가 없는 부분에서 해결되어 막상 풀고나니 허전하기 이를

데가 없었습니다. 그래서 한번 글로 남겨놓고 싶어서 이렇게 몇자 적어보았습니다.



참고 : DSPack 2.3.4  델파이 7 사용.

 

 

출처 : 델마당 dong(dongsoft) 님 글