Dyamic vs Static Polymorphism в C++: что предпочтительнее?

Question

Я понимаю, что динамический/статический полиморфизм зависит от дизайна приложения и требований. Однако целесообразно ли ВСЕГДА выбрать статический полиморфизм по сравнению с динамическим, если это возможно? В частности, я не вижу следующий выбор 2 дизайн в моем приложении, оба из которых, как представляется, не рекомендуемые:

1. Реализация статического полиморфизма с использованием CRTP: Нет виртуальные таблицы накладных расходов подстановок, обеспечивая при этом интерфейс в виде шаблона базовый класс. Но, использует Лот переключателя и static_cast для доступа правильного класса/метода, который является опасной

2. Динамического полиморфизмом: Реализовать интерфейсы (чисто виртуальные классы), связывая стоимость поиска для даже тривиальных функций, таких как Accessors/мутаторы

Мое приложение очень критично, поэтому я в пользу статического полиморфизма. Но нужно знать, является ли использование слишком большого количества static_cast показателем плохого дизайна и как избежать этого, не вызывая латентности.

EDIT: Спасибо за понимание. Принимая конкретный случай, какой из них является лучшим подходом?

class IMessage_Type_1 
{ 
    virtual long getQuantity() =0; 
... 
} 
class Message_Type_1_Impl: public IMessage_Type_1 
{ 
    long getQuantity() { return _qty;} 
... 
} 

ИЛИ

template <class T> 
class TMessage_Type_1 
{ 
    long getQuantity() { return static_cast<T*>(this)->getQuantity(); } 
... 
} 
class Message_Type_1_Impl: public TMessage_Type_1<Message_Type_1_Impl> 
{ 
    long getQuantity() { return _qty; } 
... 
} 

Отметим, что существует несколько мутаторов/аксессоров в каждом классе, и мне необходимо указать интерфейс в моем приложении. В статическом полиморфизме я переключаюсь только один раз - для получения типа сообщения. Однако в динамическом полиморфизме я использую виртуальные функции для вызова метода EACH. Разве это не значит использовать статический поли? Я считаю, что static_cast в CRTP вполне безопасен и не влияет на производительность (привязка времени компиляции)?

Answer 1

Коммутатор - это не что иное, как последовательность переходов, которые после оптимизации становятся прыжком к адресу, просматриваемому таблицей. Точно так же, как вызов виртуальной функции.

Если вам нужно прыгать в зависимости от типа, вы должны сначала выбрать тип. Если выбор не может быть выполнен во время компиляции (по существу, потому что это зависит от ввода), вы всегда должны выполнять две операции: выберите & прыжок. Синтаксический инструмент , который вы используете для выбора, не меняет производительность, так как оптимизирует то же самое.

Фактически вы являетесь reinventing v-table.

Answer 2

Вы видите проблемы дизайна, связанные с полиморфизмом, основанным исключительно на шаблонах. В то время как выглядящий виртуальный базовый класс дает вам довольно хорошую идею, что ожидается от производного класса, это становится намного сложнее в сильно затененных шаблонах. Можно легко продемонстрировать это, введя синтаксическую ошибку при использовании одной из библиотек boost.

С другой стороны, вы боитесь проблем с производительностью при использовании виртуальных функций. Доказательство того, что это будет проблемой, намного сложнее.

ИМХО это не вопрос. Придерживайтесь виртуальных функций, пока не указывается иначе. Виртуальные вызовы функций намного быстрее, чем большинство людей думают (вызов функции из динамически связанной библиотеки также добавляет слой косвенности. Никто, кажется, не думает об этом).

Я бы рассматривал только шаблонный дизайн, если он упрощает чтение кода (общие алгоритмы), вы используете один из немногих случаев, которые, как известно, медленны с виртуальными функциями (числовые алгоритмы) или вы уже определили его как производительность горлышко бутылки.

Answer 3

Статические и динамические полиморфизмы предназначены для решения различных проблем , поэтому редко бывают случаи, когда оба будут уместны. В такие случаи, динамический полиморфизм приведут к более гибкому управлению и . Но большую часть времени выбор будет очевидным, по другим причинам.

Однократная категоризация двух: виртуальных функций допускает различные реализации для общего интерфейса; шаблоны позволяют использовать разные интерфейсы для общей реализации.

Answer 4

Статический полиморфизм может обеспечить значительное преимущество, если вызываемый метод может быть встроен компилятором. Например, если виртуальный метод выглядит следующим образом:

protected: 
virtual bool is_my_class_fast_enough() override {return true;} 

то статическое polimophism должно быть предпочтительным способом (в противном случае метод должен быть честным и вернуть ложные :).

Виртуальный вызов «True» (в большинстве случаев) не может быть встроен.

Других отличия (например, дополнительная косвенность в виртуальных таблицах вызова) являются пренебрежимо

[EDIT]

Однако, если вы действительно нужен во время выполнения полиморфизм (если абонент не должен знать реализация метода и, следовательно, метод не может быть встроен на стороне вызывающего абонента), то не изобретать vtable (как упоминал Эмилио Гаравалья), просто используйте его.