Мой метод для предотвращения dynamic_cast <> быстрее, чем dynamic_cast <> сам?

Единственный правильный ответ на «это быстрее?» - «попробуйте».

Когда люди говорят, что dynamic_cast медленный, это просто эмпирическое правило. dynamic_cast более или менее делает то, что вы делаете. Он медленный, потому что включает пару обращений к памяти. Это похоже на то, как люди говорят, что виртуальные функции медленные. Вы берете что-то быстрое (вызов функции) и добавляете к этому пару обращений к памяти. Это значительно замедляет работу (поскольку весь путь к памяти и обратно может занять несколько сотен циклов), но для большинства людей это не имеет значения, пока это не делается часто (с очень большим значением "часто").

Вы сосредотачиваетесь на скорости, но как насчет правильности?

Основной вопрос заключается в том, уверены ли вы, что не ошибетесь? В частности, у вас может возникнуть соблазн обернуть метод приведения таким образом:

template <class T>
T* convert(Message* message)
{
  if (message == 0) return 0;
  else return message->getType() == T::Type() ? static_cast<T*>(message) : 0;
}

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

switch(message->getType())
{
case Foo:
{
  //...
  // fallthrough
}
case Bar:
{
  BarMessage* bar = static_cast<BarMessage*>(message); // got here through `Foo`
}
}

или очевидного:

if (message->getType() == Foo) static_cast<BarMessage*>(message); // oups

Not по общему признанию, много, но это тоже не так много усилий.

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

• виртуальные методы
• Посетитель

и т. Д.

Я не вижу никаких ответов по этому поводу, но вы не можете отправлять объекты C ++ по сети и ожидать, что они прибудут в целости и сохранности. Виртуальная таблица настраивается на основе состояния памяти на передающем компьютере, вполне вероятно, что на принимающем компьютере не будет вещей в одном и том же месте. Это также обычно приводит к сбою RTTI (что и использует dynamic_cast), поскольку RTTI часто реализуется вместе с vtable.

У вас уже есть абстрактный базовый класс " Сообщение". Используйте его как интерфейс, чтобы скрыть детали реализации FooMessage и BarMessage.

Думаю, именно поэтому вы выбрали этот подход, или нет?

A) Это очень похоже на преждевременную оптимизацию.

Б) Если ваш проект требует так много вызовов dynamic_cast<>, что вы беспокоитесь об этом, то вам определенно нужно взглянуть на свой проект и понять, что в нем не так.

C) Как сказано в предыдущем ответе, единственный способ ответить, быстрее ли это, это использовать профилировщик (или эквивалент) и провести сравнение.

Это зависит от того, как вы управляете своими сообщениями. Когда у меня есть switch для выбора сообщения на основе типа, лучшим вариантом будет использование static_cast, так как вы знаете, что парсер функции даст вам создать правильный тип.

Message* gmsg parse(frame);

switch (gmsg->type) {
  case FooMessage_type:
    FooMessage* msg=static_cast<FooMessage*)(gmsg);
    // ...
    break;
  case BarMessage_type:
    BarMessage* msg=static_cast<BarMessage*)(gmsg);
    //...
    break;      
};

Использование dynamic_cast здесь является чрезмерной защитой.

Зачем вам нужно, чтобы все сообщения наследовались от общего? В чем заключается общность? Я добавлю еще одну конструкцию, которая вообще не использует наследование

switch (frame::get_msg_type(aframe)) {
  case FooMessage_type:
    FooMessage msg=parse<FooMessage)(aframe);
    // work with msg
    break;
  case BarMessage_type:
    BarMessage msg=parse<BarMessage)(aframe);
    //...
    break;
};

где parse разбирает фрейм как MSG, или бросает исключение, когда разбор не удался.

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