2013-06-26 3 views
0

아래쪽에서 답합니다. 감사!왜 RUMTIME_CLASS가 "DECLARE_DYNAMIC"없이 VS2008 디버그 버전으로 컴파일 되었습니까?

컴파일러에서 릴리스 버전에서 C2039 및 C2065 오류가 올바르게 발생했습니다.

왜 같은 코드가 디버그 버전에서 컴파일을 통과 할 수 있는지 궁금합니다.

알려진 Microsoft 버그입니까?

나는 DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC이 문제를 해결할 것임을 알고 있습니다. 그러나, 그것들이 없으면 왜 Microsoft는 내 디버그 버전에서 컴파일을 통과 했습니까? 이것이 문제입니다.


이유가 알려져 있습니다. 마이클의 대답은 정확합니다. _AFXDLL은 디버그 구성에서만 정의됩니다. 그래서 디버그 버전에서는 매크로 RUNTIME_CLASS를 확장 할 때 CObject :: GetThisClass를 사용합니다. DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC 선언되지 않은 경우

은 그래서 다음 코드는 모두 릴리스 및 디버그 버전의 컴파일러 오류가 잡힐 것 _AFXDLL이 미리 정의되어 있지 않은 경우

CRuntimeClass* p = (CRuntimeClass*) (&XXX::classXXX); 

그러나 다음 코드는 실패합니다.

p->IsKindOf(RUNTIME_CLASS(XXX)) 

감사

+1

소스 코드를 게시하고 오류 메시지의 텍스트를 표시 할 수 있습니까? –

+0

오류 C2039 : 'classXXXX': 'XXXX'의 구성원이 아니며 오류 C2065 : 'classXXXX': 선언되지 않은 식별자 – milesma

+1

나만인가, 아니면 단순히 합리적인 수준의 노력이없는 질문이 넘쳐 흐르고 있습니까? 그들에게 답을 줄 수 있도록 그들을 넣었습니까? –

답변

1

가능성이 설명은 릴리스 구성이 정적 MFC 런타임에 연결하는 동안 디버그 프로젝트 구성이 MFC DLL 런타임에 연결되어 있다는 점이다. _AFXDLL가 정의 그래서

#ifdef _AFXDLL 
    static CRuntimeClass* PASCAL _GetBaseClass(); 
    static CRuntimeClass* PASCAL GetThisClass(); 
#endif 

: afx.h에서 MFC DLL 대하여 CObject베이스 객체 정의를 작성하면합니다 (MFC DLL이 사용되는 것을 나타낸다) 정의 _AFXDLL 매크로 존재로 인해 활성화 다음 행을 갖는다 CObject에서 파생 된 모든 객체는 DECLARE_DYNAMIC()으로 더 잘 일치하지 않는 경우 RUNTIME_CLASS()이 끝나는 고정 GetThisClass() 함수를 가져옵니다. _AFXDLL가 정의되어 있지 않으면

GetThisClass() 기능은 CObject에 선언되지 않는다 - 당신이 DECLARE_DYNAMIC() 매크로를 사용하고 정의를 얻을 수 IMPLEMENT_DYNAMIC()를 사용해야하는 클래스에 대한 하나를 얻을 수 있습니다.

차이점은 아마도 디버그 대 릴리즈가 아니라 MFC DLL 대 MFC 정적 런타임 차이입니다.

+0

"_DEBUG와 NDEBUG"를 바꾸는 것의 의미가 확실하지 않다. –

+0

이유를 아십시오. 귀하의 답변은 정확합니다. _AFXDLL은 디버그 구성에서만 정의됩니다. 그래서 디버그 버전에서는 매크로 RUNTIME_CLASS를 확장 할 때 CObject :: GetThisClass를 사용합니다. – milesma