Почему RUMTIME_CLASS прошел компиляцию без & quot; DECLARE_DYNAMIC & quot; в VS2008 отладочной версии?
Ответил внизу. Спасибо!
Компилятор правильно уловил ошибки C2039 и C2065 в версии Release;
Мне просто любопытно, почему один и тот же код МОЖЕТ пройти компиляцию в версии Debug?
Это известная ошибка Microsoft?
Я знаю, что DECLARE_DYNAMIC / IMPLEMENT_DYNAMIC решит проблему. Однако, без них, почему Microsoft передала компиляцию в моей отладочной версии? Это вопрос.
Известная причина. Майкл ответ точно правильно. _AFXDLL определяется только в моей конфигурации отладки. Поэтому в отладочной версии он использует CObject :: GetThisClass при развертывании макроса RUNTIME_CLASS.
Таким образом, следующий код будет перехвачен ошибкой компилятора как для версии Release, так и для версии Debug, если DECLARE_DYNAMIC / IMPLEMENT_DYNAMIC не было объявлено:
CRuntimeClass* p = (CRuntimeClass*) (&XXX::classXXX);
Но следующий код потерпит неудачу, только если _AFXDLL не задан заранее.
p->IsKindOf(RUNTIME_CLASS(XXX))
Спасибо
Решение
Вероятное объяснение состоит в том, что конфигурация вашего проекта отладки связана со средой выполнения MFC DLL, а конфигурация вашего выпуска связана со статической средой выполнения MFC. При сборке против MFC DLL CObject определение базового объекта в afx.h следующие строки включены из-за _AFXDLL определяемый макрос (который указывает, что MFC DLL используется):
#ifdef _AFXDLL
static CRuntimeClass* PASCAL _GetBaseClass();
static CRuntimeClass* PASCAL GetThisClass();
#endif
Так когда _AFXDLL определяется, все объекты получены из CObject получить статический GetThisClass() функция, которая есть что RUNTIME_CLASS() заканчивает тем, что звонит, если нет лучшего соответствия, представленного DECLARE_DYNAMIC(),
Если _AFXDLL не определено, GetThisClass() функция не объявлена в CObject — чтобы получить один для класса, вы должны использовать DECLARE_DYNAMIC() макрос и использование IMPLEMENT_DYNAMIC() чтобы получить определение.
Таким образом, разница, вероятно, не отладочная версия против выпуска, это MFC DLL против статической разницы времени выполнения MFC.
Другие решения
Других решений пока нет …