RTTIを使用するよりも「純粋なポリモーフィズム」が望ましいのはなぜですか？
この種のことを説明しているほとんどすべてのC ++リソースは、RTTI（ランタイム型識別）を使用するよりもポリモーフィックなアプローチを好むべきだと私に教えています。一般に、私はこの種のアドバイスを真剣に受け止め、その根拠を理解しようとします-結局のところ、C ++は強力な獣であり、その完全な深さを理解することは困難です。ただし、この特定の質問については、空白を描いています。インターネットがどのようなアドバイスを提供できるかを確認したいと思います。まず、RTTIが「有害であると見なされている」理由として引用されている一般的な理由を挙げて、これまでに学んだことを要約しましょう。 一部のコンパイラはそれを使用しません/ RTTIは常に有効ではありません 私は本当にこの議論を買いません。これは、C ++ 14の機能を使用するべきではないと言っているようなものです。C++ 14の機能をサポートしていないコンパイラが世に出ているからです。それでも、C ++ 14機能の使用を思いとどまらせる人はいません。プロジェクトの大部分は、使用しているコンパイラーとその構成方法に影響を与えます。gccのマンページを引用しても： -fno-rtti C ++ランタイム型識別機能（dynamic_castおよびtypeid）で使用する仮想関数を持つすべてのクラスに関する情報の生成を無効にします。言語のこれらの部分を使用しない場合は、このフラグを使用してスペースを節約できます。例外処理は同じ情報を使用しますが、G ++は必要に応じてそれを生成することに注意してください。dynamic_cast演算子は、実行時の型情報を必要としないキャスト、つまり「void *」または明確な基本クラスへのキャストに引き続き使用できます。 これは、RTTIを使用していない場合は無効にできることを示しています。つまり、Boostを使用していない場合は、Boostにリンクする必要はありません。誰かがでコンパイルする場合を想定する必要はありません-fno-rtti。さらに、この場合、コンパイラは大音量でクリアします。 追加のメモリが必要/遅くなる可能性がある RTTIを使いたくなったときはいつでも、ある種の型情報やクラスの特性にアクセスする必要があります。RTTIを使用しないソリューションを実装する場合、これは通常、この情報を格納するためにいくつかのフィールドをクラスに追加する必要があることを意味します。そのため、memory引数は一種の無効です（この例は後で説明します）。 実際、dynamic_castは遅くなる可能性があります。ただし、スピードが重要な状況での使用を回避する方法は通常いくつかあります。そして、私は代替案をまったく見ていません。このSOの回答は、基本クラスで定義された列挙型を使用して型を格納することを提案しています。これは、すべての派生クラスを事前に知っている場合にのみ機能します。それはかなり大きな「もし」だ！ その回答から、RTTIのコストも明確ではないようです。異なる人々は異なるものを測定します。 エレガントなポリモーフィックデザインはRTTIを不要にします これは私が真剣に受け止めている一種のアドバイスです。この場合、自分のRTTIユースケースをカバーする優れた非RTTIソリューションを思い付くことはできません。例を挙げましょう。 ある種のオブジェクトのグラフを処理するライブラリを書いているとしましょう。ライブラリを使用するときにユーザーが独自の型を生成できるようにしたい（そのため、enumメソッドは使用できません）。私のノードの基本クラスがあります： class node_base { public: node_base(); virtual ~node_base(); std::vector< std::shared_ptr<node_base> > get_adjacent_nodes(); }; 現在、私のノードはさまざまなタイプにすることができます。これらはどうですか： class red_node : virtual public node_base { public: red_node(); virtual ~red_node(); void get_redness(); …