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

Чрезмерное использование ООП — один из примеров такой вещи. Давайте возьмем ваш пример Expr, который является узлом в дереве выражений. И вы можете задавать ему вопросы, например, является ли это бинарной операцией, унарной операцией или нулевой операцией (к вашему сведению: литеральные значения являются нулевыми, а не унарными. Они не принимают аргументов).

Где вы злоупотребляли ООП, так это в попытке дать каждому оператору свой собственный тип класса. Чем отличается оператор сложения от оператора умножения? Приоритет? Это вопрос грамматики; это не имеет значения, если вы построили дерево выражений. Единственная операция, которая действительно заботится о конкретном бинарном операторе, — это когда вы его вычисляете. И даже при выполнении оценки единственная особенная часть — это когда вы берете результаты оценки операндов и вводите их в код, который будет производить результат этой операции. Все остальное одинаково для всех бинарных операций.

Итак, у вас есть одна функция, которая отличается для разных бинарных операций. Если изменяется только одна функция, вам действительно не нужны разные типы только для этого. Гораздо разумнее, чтобы разные бинарные операторы были разными значениями в пределах общего класса BinaryOp. То же самое касается UnaryOp и NullaryOps.

Таким образом, в этом примере есть только 3 возможных типа для любого заданного узла. И это очень разумно иметь дело с variant<NullaryOp, UnaryOp, BinaryOp>. Таким образом, Expr может просто содержать один из них, причем каждый тип операнда имеет ноль или более указателей на его дочерние элементы Expr. В Expr может быть общий интерфейс для получения количества дочерних элементов, перебора дочерних элементов и т. д. А различные типы Op могут предоставлять реализации для них с помощью простых посетителей.

Большинство случаев, когда вы начинаете хотеть делать даункастинг и подобные вещи, — это случаи, которые можно решить лучше и чище, используя другие механизмы. Если вы строите иерархии без функций virtual, где код, получающий базовые классы, уже знает большинство или все возможные производные классы, велика вероятность, что вы действительно пишете грубую форму variant.

Вас может заинтересовать Curious Recursing Template Pattern здесь, чтобы вообще избежать необходимости в виртуальном методе, если вы знаете тип экземпляра во время компиляции.

template <typename Impl> 
class Base_virt {
public:
    Base_virt(Kind p_kind) noexcept : m_kind{p_kind}, m_x{} {}

    [[nodiscard]] inline Kind
    get_kind() const noexcept { return Impl::kind(); }

    [[nodiscard]] inline int
    get_x() const noexcept {
        return m_x;
    }

    [[nodiscard]] inline int get_y() const noexcept { 
        return static_cast<const Impl*>(this)->get_y(); 
    }

private:
    int m_x;
};


class A_virt final : public Base_virt<A_virt> {
public:
    A_virt() noexcept : Base_virt{Kind::A}, m_y{} {}

    [[nodiscard]] inline static Kind kind() { return Kind::A; }

    [[nodiscard]] inline int
    get_y() const noexcept final {
        return m_y;
    }

private:
    int m_y;
};

// Copy/paste/rename for B_virt

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

template <typename Impl>
static void
crtp_cast_check(benchmark::State& p_state) noexcept {
    auto const a = A_virt();
    Base_virt<Impl> const* ptr = &a;

    for (auto _ : p_state) {
        benchmark::DoNotOptimize(ptr->get_y());
    }
}
BENCHMARK(crtp_static_cast_check<A_virt>);

Это, вероятно, скомпилировано в прямой вызов for(auto _ : p_state) b::dno(m_y). Недостатком этого подхода является раздутое двоичное пространство (у вас будет столько экземпляров функции, сколько дочерних типов), но это будет самым быстрым, поскольку компилятор выведет тип во время компиляции.

С подходом BaseTag это будет выглядеть так:

   class BaseTag { virtual Kind get_kind() const = 0; }; 
   // No virtual destructor here, since you aren't supposed to manipulate instance via this type

   template <typename Impl>
   class Base_virt : BaseTag { ... same as previous definition ... };

   // Benchmark method become
   void virt_bench(BaseTag & base) {
     // This is the only penalty with a virtual method:
     switch(base.get_kind()) {

       case Kind::A : static_cast<A_virt&>(base).get_y(); break;
       case Kind::B : static_cast<B_virt&>(base).get_y(); break;
       ...etc...
       default: assert(false); break; // At least you'll get a runtime error if you forget to update this table for new Kind
     }
     // In that case, there is 0 advantage not to make get_y() virtual, but
     // if you have plenty of "pseudo-virtual" method, it'll become more 
     // interesting to consult the virtual table only once for get_kind 
     // instead of for each method
   }

   template <typename Class>
   void static_bench(Class & inst) {
     // Lame code:
     inst.get_y();
   }

   A_virt a;
   B_virt b;

   virt_bench(a);
   virt_bench(b);

   // vs
   static_bench(a);
   static_bench(b);

Извините за псевдокод выше, но вы поняли.

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

Возможное решение — сделать get_kind() функцией virtual. Затем вы можете использовать dynamic_cast. Если вы собираетесь вызывать много функций virtual, вы можете понизить его до наиболее производного класса, чтобы оптимизатор мог оптимизировать вызовы virtual. Вы также захотите использовать наследование virtual (например, class Unary_expr : public virtual Expr {};, если у вас нет членов данных в базовом классе для правильного использования памяти. Наличие указателя на vtable занимает 8 байтов на 64-битной машине, поэтому вы можете быть вынуждены использовать дискриминацию для уменьшения размера каждого объекта (но это, очевидно, имеет смысл только в том случае, если не будут использоваться абсолютно никакие функции virtual).

Этот метод решает следующую проблему, поднятую в руководящих принципах:

... Тем не менее, по нашему опыту, такие ситуации, как я знаю, что делаю, по-прежнему являются известным источником ошибок.

@ xryl669 указывает, что любопытный шаблон рекурсивного шаблона или CRTP можно использовать для устранения необходимости проверки типа во время выполнения, если вы знаете, с каким типом имеете дело. Он также освещает проблему и решение метода, поэтому вам обязательно следует проверить его ответ.

Вот еще один ресурс по CRTP, который мне показался полезным: Стоимость динамической (виртуальные вызовы) и статической (CRTP) отправки в C++

class Expr {
public:
    enum class Kind : unsigned char {
        Int_lit_expr,
        Neg_expr,
        Add_expr,
        Sub_expr,
    };

    [[nodiscard]] virtual Kind get_kind() const noexcept = 0;

    [[nodiscard]] virtual bool
    is_unary() const noexcept {
        return false;
    }

    [[nodiscard]] virtual bool
    is_binary() const noexcept {
        return false;
    }
};


class Unary_expr : public virtual Expr {
public:
    [[nodiscard]] bool
    is_unary() const noexcept final {
        return true;
    }

    [[nodiscard]] Expr const*
    get_expr() const noexcept {
        return m_expr;
    }

protected:
    explicit Unary_expr(Expr const* p_expr) noexcept : m_expr{p_expr} {}

private:
    Expr const* const m_expr;
};


class Binary_expr : public virtual Expr {
public:
    [[nodiscard]] bool
    is_binary() const noexcept final {
        return true;
    }

    [[nodiscard]] Expr const*
    get_lhs() const noexcept {
        return m_lhs;
    }

    [[nodiscard]] Expr const*
    get_rhs() const noexcept {
        return m_rhs;
    }

protected:
    Binary_expr(Expr const* p_lhs, Expr const* p_rhs) noexcept : m_lhs{p_lhs}, m_rhs{p_rhs} {}

private:
    Expr const* const m_lhs;
    Expr const* const m_rhs;
};


class Add_expr final : public Binary_expr {
public:
    Add_expr(Expr const* p_lhs, Expr const* p_rhs) noexcept : Binary_expr{p_lhs, p_rhs} {}

    [[nodiscard]] Kind get_kind() const noexcept final {
        return Kind::Add_expr;
    }
};


int main() {
    auto const add = Add_expr{nullptr, nullptr};
    Expr const* const expr_ptr = &add;

    if (expr_ptr->is_unary()) {
        // NOLINTNEXTLINE(clang-analyzer-deadcode.DeadStores): it is just an example
        auto const* const expr = dynamic_cast<Unary_expr const* const>(expr_ptr)->get_expr();

    } else if (expr_ptr->is_binary()) {
        // NOLINTNEXTLINE(clang-analyzer-deadcode.DeadStores): it is just an example
        auto const* const lhs = dynamic_cast<Binary_expr const* const>(expr_ptr)->get_lhs();
    
        // NOLINTNEXTLINE(clang-analyzer-deadcode.DeadStores): it is just an example
        auto const* const rhs = dynamic_cast<Binary_expr const* const>(expr_ptr)->get_lhs();
    }
}

Все эти аргументы замечательны, но есть случаи, когда эти решения неприменимы. Одним из примеров является опытная спецификация JNI. Sony добавила оболочку C++ в официальный Java Native Interface в последнюю очередь. Например, они определяют метод GetObjectField(), который возвращает jobject. Но если поле является массивом, вы должны привести его к jbyteArray, например чтобы иметь возможность использовать GetArrayLength().

Невозможно использовать dynamic_cast с JNI. Альтернативы: либо приведение в стиле C, либо static_cast, и я считаю, что последнее безопаснее или, по крайней мере, чище, чем

(jbyteArray)env->CallObjectMethod(myObject, toByteArray_MethodID);

Чтобы подавить предупреждение в Android Studio для одной строки, используйте NOLINT:

auto byteArray = static_cast<jbyteArray>(env->CallObjectMethod(myObject, toByteArray_MethodID)); // NOLINT(cppcoreguidelines-pro-type-static-cast-downcast)

Или, установите

#pragma ide diagnostic ignored "cppcoreguidelines-pro-type-static-cast-downcast"

для файла или блока