지나다가님 답변해주신거 잘봤습니다
옛날 터보파스칼 부터 rad xe4 빌더에 이르기 까지 엠바카데로 개발툴을 오랫동안 써왔지만
__classid가 vmt 와 rtti를 동시에 참조한다는 사실은 지나다가님 글을 통해서 처음 알게되었습니다
답변해주신 내용을 보면 __classid를 이용해서 rtti도 알수있을거 같은데요,, rtti를 잘알고있을 정도의 실력을
갖고계신 분이 지나다가님 밖에 없을것 같네요. 한수 가르쳐 주시면 감사하겠습니다. 꾸벅~

지나다가님이 못보신거 같아서 다시 여쭙니다. 예제라도 올려주시면 더욱 감사하겠습니다.


지나다가 님이 쓰신 글 :
: 비스 님이 쓰신 글 :
: : VS2013 프리뷰가 나와서 잠깐 돌려봤는데 IDE가 더 막강해졌더군요
: : 디버깅할때 함수호출관계를 그래프로 보여주는 기능은 환상적이던데
: :
: : 비쥬얼스튜디오는 IDE가 점점 더 막강해지는데, 그에 비하면 RAD IDE는
: : 솔직이 메모장 수준 밖에 안되죠.
: :
: : 저야 실력이 없어서 엄두도 못내지만 RAD bin 디렉토리에 있는 coreide180.bpl
: : 같은 것을 이용해서 비쥬얼 스튜디오 IDE에 RAD XE4를 통합할수 있다면
: : 굉장히 사용하기 편할거라는 생각이드는데 이런것도 가능할까요?
: :
:
:
: BDS.EXE를 사용하지 않고 MS사의 Visual Studio IDE에 RAD XE4를 통합하는 것은 가능하기는 하나 델파이 쪽에서 닭짓을 해놔서
: 실현성이 없다고 봐야 함. Tools API, COREIDE180 등을 활용하려고 해도 델파이에서 기본적으로 사용되는 calling convention이
: __fastcall 방식인데, __fastcall 호출방식은 컴파일러 업계 표준이 아니고, 컴파일러 벤더마다 방식이 다름.
:
: 예를 들어서 Visual C++ 에서
:
: void __fastcall foo(int a, int b, int c, int d, int e)
: {
: }
:
: 은
:
: 오른쪽 부터 스택에 e, d, c 순으로 값을 넣고 b와 a는 각기 edx, ecx 레지스터를 이용하는 반면
:
: 델파이의 경우는
:
: implementation
:
: procedure foo(a, b, c, d, e: Integer);
: begin
: end;
:
: 스택에 d, e 순으로 값을 넣고 c,b,a를 각기 ecx, edx, eax 레지스터를 이용하고 있음
:
:
: Visual Studio IDE 핵심 코어는 ATL을 이용한 C++ COM으로 구현되어 있고
: 예를 들어 IServiceProvider 인터페이스를 예로 들면
:
:     typedef struct IServiceProviderVtbl
:     {
:         BEGIN_INTERFACE
:        
:         HRESULT ( STDMETHODCALLTYPE *QueryInterface )(
:             __RPC__in IServiceProvider * This,
:             /* [in] */ __RPC__in REFIID riid,
:             /* [annotation][iid_is][out] */
:             _COM_Outptr_  void **ppvObject);
:        
:         ULONG ( STDMETHODCALLTYPE *AddRef )(
:             __RPC__in IServiceProvider * This);
:        
:         ULONG ( STDMETHODCALLTYPE *Release )(
:             __RPC__in IServiceProvider * This);
:        
:         /* [local] */ HRESULT ( STDMETHODCALLTYPE *QueryService )(
:             IServiceProvider * This,
:             /* [annotation][in] */
:             _In_  REFGUID guidService,
:             /* [annotation][in] */
:             _In_  REFIID riid,
:             /* [annotation][out] */
:             _Outptr_  void **ppvObject);
:        
:         END_INTERFACE
:     } IServiceProviderVtbl;
:
: 위와 같이 COM 호출방식 표준인 __stdcall 방식으로 되어 있기 때문에
: 델파이 코드와 인터페이스를 취하기 위해선 __fastcall 호출방식으로 되어 있는 델파이쪽의 모든 프로시져와 펑션들을
: __stdcall 로 바꾸기 위한 Thunk 코드를 일일히 구현해 줘야 함. 프로시져와 펑션이 한두개도 아니고 이건 실현성이 없음.
:
: Tools API의 경우도 델파이 랭귀지에선 클래스 다중 상속이 지원되지 않기 때문에 COM Interface 방식으로 구현되어 있는데
: 멍청한 놈들이 Tools API 마져 calling convention을 COM 표준인 __stdcall을 사용하지 않고, 디폴트 방식인 __fastcall 방식으로
: 닭짓을 해놓았기 때문에 이 또한 호출방식을 변경하는 Thunk코드를 일일히 구현해 줘야함.
:
:
: 델파이가 __fastcall 방식을 사용한 데는 컴파일러 구현이론에 대한 비하인드 스토리가 있음.
:
: 델파이가 처음 나왔을 당시 Code Optimizing 기술은 원시적인 수준이었고, 레지스터를 이용하는 __fastcall 호출방식이
: 역할을 하기도 했지만, Optimizing 기법이 발달한 지금에 와서는 오히려 __fastcall 방식은 최적화를 방해하는 요소가 돼 버림.
:
: 왜냐하면 파라미터 전달로 특정 레지스터 사용이 정해져 버리면, 옵티마이져가 코드를 최적화 할때 레지스터 풀로 사용할
: 리소스가 제한되어 글로벌 옵티마이징에 방해가 되기 때문임.
:
: void foo()
: {
:       register int a, b, c;
: }
:
: 옛날엔 실행속도를 높이기 위해서 스택변수를 레지스터를 이용하라는 식으로 가르치기도 했지만, 위에서 언급한 대로
: 이런 방식은 글로벌 옵티마이징을 오히려 방해하는 요인으로 작용하기 때문에 레지스터를 할당하는 register 같은 키워드도 이젠
: 역사속으로 사라져 버렸음.
:
: __fastcall 방식은 간단한 루프에서나 효과가 있을 뿐, 펑션 또는 프로시져의 알고리즘이 복잡하면 복잡해질수록 옵티마이징에서는
: 더 불리한 결과를 초래하게 됨.
:
: 그리고 __fastcall 방식의 경우 디버깅 모드에서 최적화 하지도 않는데도 불구하고, 가끔 디버깅시 코드가 최적화 되어서
: 파라미터를 인스펙트 할수 없다고 나오는데, 이건 엄밀하게 보면 최적화 되어서 그런게 아니고 파라미터와 생성된 코드에서
: 사용되는 레지스터가 Confilct가 일어나서 디버거가 심볼을 Resoving 할수 없기 때문이지 최적화 때문이 아님.
:
:
: 사족으로 닷넷에 대한 얘기도 보이던데, 닷넷은 결코 느리지 않음.
: 닷넷이 느리지 않은 이유는 네이티브 컴파일러로는 불가능한 지터의 독특한 내부 동작방식 때문인데,
: 이건 다음 기회에 다뤄 보겠음. ㅋ
:
:
:
: