Предположим, что некоторый класс C++ «SubClass» расширяет класс «BaseClass», затем при отладке программы в VS2017 и прерывается в некоторой точке останова в некоторой функции-члене любого из классов в панели «Локальные» в VS2017 столбец «Тип» в столбце « this "должен отображать" SubClass "(то есть реальный тип, а не какой-то базовый тип), если" this "является экземпляром" SubClass ".
Но иногда для некоторых сложных приложений это не работает, и отображается имя базового класса для типа «this», если точка останова находится в каком-либо методе базового класса.
Когда это произойдет и как это исправить?
Приложение:
Одним из примеров является отладка clang 6.0 в VS2017 и установка точки останова в методе
void MCObjectStreamer::EmitFrames(MCAsmBackend *MAB)
в MCObjectStreamer.cpp. Когда break, тип «this» отображается как «llvm: MCObjectStreamer», но «this» действительно является некоторым подклассом «X86WinCOFFStreamer». Перейти на один шаг вверх по стеку вызовов и в методе (подкласса X86WinCOFFStreamer)
void X86WinCOFFStreamer::FinishImpl()
"this" правильно отображается как "X86WinCOFFStreamer"
@prapin У прямого базового класса его нет, но у MCObjectStreamer есть. X86WinCOFFStreamer расширяет MCWinCOFFStreamer (без виртуального) расширяет MCObjectStreamer (имеет виртуальный)
@prapin Плюс содержимое this в любом случае в конечном итоге приведет к __vfptr самого базового класса. MCObjectStreamer расширяет MCStreamer, который является самым базовым классом.
Есть ли в базовом классе (хотя бы) один виртуальный метод? Если этого не произойдет, отладчик в контексте
MCObjectStreamer
не сможет узнать тип производного класса (dynamic_cast
также потерпит неудачу).