литье — Практическое использование использования RTTI в переполнении стека
Сделав с 1-й том. «Размышления на С ++» Брюса Экеля, я начал читать 2-й том. Глава, посвященная RTTI (Идентификация типа во время выполнения) поражает меня больше всего. Я читал о tyepid, dynamic_cast, так далее.
Но у меня вопрос всплывает в моей голове. Являются ли их практическим использованием эксплуатации RTTI через упомянутых операторов, то есть несколько примеров из реальных проектов? Кроме того, какие были ограничения, которые сделали его использование необходимым?
Решение
dynamic_cast может быть полезен для добавление дополнительная функциональность
void foo(ICoolStuff *cs)
{
auto ecs = dynamic_cast<IEvenCoolerStuff*>(cs);
if (ecs != 0)
{
ecs->DoEvenCoolerStuff();
}
cs->DoCoolStuff();
}
когда вы разрабатываете с нуля, это может быть возможно поставить DoEvenCoolerStuff в ICoolStuff и иметь пустые реализации в классах, которые не поддерживают его, но это часто неосуществимо, когда вам нужно изменить существующий код.
Другое использование — реализация системы обмена сообщениями, где можно использовать dynamic_cast для различения сообщений, которые вас интересуют. В более общем смысле это может вам понадобиться при столкновении с проблема выражения.
Другие решения
Наиболее распространенный пример RTTI в производственном коде, который я видел в своих путешествиях, это dynamic_cast, но это почти всегда используется как лейкопластырь для плохого дизайна.
dynamic_cast полезен в основном для полиморфных классов, а затем для перехода от базового к производному. Но подумай об этом. Если у вас есть базовый указатель на правильно разработанный полиморфный класс, зачем вам вообще указатель на производный тип? Теоретически, вам нужно всего лишь позвонить virtual функции, и имеют фактическую реализацию решения с деталями реализации.
Теперь, как говорится, есть случаи, когда даже dynamic_cast это лейкопластырь, это все еще меньшее из двух зол. Это особенно верно, когда «исправление» сломанной конструкции подразумевало бы большой проект технического обслуживания и не повлияло бы на производительность. Предположим, у вас есть приложение на 1 MLOC, и исправление чего-то, что было сломано академически, означало бы необходимость касаться 100 тыс. Строк кода. Если нет никаких причин для внесения этого изменения в производительность, то вы исправляете его просто ради исправления, но вы рискуете создать десятки или сотни новых ошибок. Это может не стоить того.