Q/A 게시판 답변해주신 글들 흥미롭게 읽었는데요, 지금 이글도 마찬가지고요, 감사합니다
제가 하고자 하는 작업이 RAD IDE 개발환경에서 C++ 프로젝트가 컴파일 될 때 MS 빌드엔진과 연동해서
다른 작업을 병행처리 하려는데요. RAD 설치되어있는 디렉토리 가보니까 /bin에 Borland.Build.Task.Cpp.dll 이 있더군요.
파일 보니까 닷넷 어셈블리 모듈이고요.

RAD IDE 환경에서 컴파일 하면 MS 빌드엔진이 Borland.Build.Task.Cpp.dll 어셈블리 모듈과 함께 연동되어 돌아가는거
같은데 맞나요? 맞다면 RAD IDE에 의해서 빌드엔진이 연동되어 돌아갈 때,, 제가 만든 어셈블리 모듈도 같이 연동되어
실행되게 하려는 작업이 가능한지 궁금합니다. 그리고 C#으로 어셈블리 모듈을 만들 때 async, await 를 이용해서
패러렐로 병행처리 하는 것도 가능한지요? 답변 글 쭉 보니까,,, 고수의 아우라가 느껴지는,,, 답변해주시면 감사하겠습니다..




지나다가 님이 쓰신 글 :
: 성현 님이 쓰신 글 :
: : 본인은 C++ 빌더를 주로 씁니다
: : 가끔 Tools API를 사용하면 좋겠다는 생각을 하다가도
: : IDesignWindow, IDesignNotification, IEditHandler, IActivatable 등등
: : 인터페이스로 만들어 놓아서 사용하려면 골치만 아프고 되게 깝깝하네요
: :
: : ActiveX도 아니고 그렇다고 COM 도 아니면서 뭐하러 이딴 식으로 Toools API를
: : 만들어놨는지 이해가 안되네요. 쩝
: :
: :
:
:
: COM Interface 방식을 안쓰고 일반적인 방식으로 구현하려고 해도, 델파이 파스칼 랭귀지는
: class multiple inheritence 를 근본적으로 언어차원에서 지원하지 않기 때문에 Interface 방식을
: 사용할 수 밖에 없음.
:
: 클래스 다중 상속을 지원하지 않는 언어에서 Interface 방식은 사실상 언어의 한계를 우회하기
: 위한 방법으로 많이 쓰임. C# 또한 그렇고.
:
: 또한 Interface 를 이용하면
:
: class CSomeServiceProvider : IInterfaceA, IInterfaceB, IInterfaceC
: {
:              .....
: };
:
: HRESULT STDMETHODCALLTYPE QueryInterface( REFIID riid, VOID **ppvInterface)
:     {
:         if (IID_IUnknown == riid)
:         {
:             AddRef();
:             *ppvInterface = (IUnknown*)this;
:         }
:         else if (__uuidof(IID_IInterfaceA) == riid)
:         {
:             AddRef();
:             *ppvInterface = (IInterfaceA*)this;
:         }
:         else if (__uuidof(IID_IInterfaceB) == riid)
:         {
:             AddRef();
:             *ppvInterface = (IInterfaceB*)this;
:         .,..
: }
: 클라이언트에서 CSomeServiceProvider 객체 하나를 통해서 객체를 캐스트 하는 것만으로도
: 필요한 인터페이스를 취할 수 있기 때문에(같은 this 포인터 이기 때문에) 사용하기 편리한
: 잇점이 되고, 이건 COM이 갖는 장점이기도 함.
:
: 사족으로 엠바가 닷넷을 포기하지 못하고, 또 툴을 설치하면 필연적으로 닷넷 설치 과정이 따르게 되는데
:
: 이건 근본적으로 엠바가 프로젝트 빌드시스템으로 MS사의 Build Engine을 사용하고 있기 때문임.
: MS사의 빌드엔진 자체가 닷넷으로 구현되어 있음. 그래서 필연적으로 닷넷을 설치할수 밖에 없음.
:
: 엠바가 자사의 Make를 통한 빌드시스템을 포기하고 MS사의 빌드엔진을 선택한 이유는 MS사의 빌드엔진이 빠르기 때문임.
: 하나의 소스를 다시 컴파일해야 할지 아닐지를 판단하기 위해선 디펜던시로 걸리는 수백 수천개의 헤더파일들 중에서 하나라도
: 변경된게 있는지 없는지 사전에 체크해야 할 필요가 있는데, 기존의 방식은 시스템 API를 매번 호출해서 파일 변경여부를 확인하는
: 방식이라 느렸지만
:
: MS사의 빌드시스템은 파일 관련한 API들을 후킹하고 있어서, 파일 변경여부를 체크하기 위해 반복적으로 API를 호출할 필요 없이
: 사전 탐지가 가능하기 때문에 빌드 속도가 매우 빨라서, 엠바에서도 오래전 부터 MS사의 빌드엔진을 채택하게 된 것임.
: 우리 엠바는 MS사의 빌드엔진 사용하면서 빌드속도 빨라졌어요 라고 광고하면서 ㅋ
:
: 엠바 IDE는 껍데기에 불과하고 디펜던시 체크, 컴파일, 리빌드 그런 과정은 MS빌드 엔진에 의해서 이루어지게 됨.
:
: