仮想継承を行った場合，dynamic_cast<Subclass*>(baseClassPointer)としてダウンキャストすることが可能である．
ダウンキャストに失敗した場合はNULLが返される．これを利用して，特定の派生クラスのみに異なる処理を与えることが可能である．
例えば
一方，モデルとして
と，Shapeのコンテナがあるとする．(特定の図形ごとにコンテナを分けるのはナンセンス)
特定の幾何図形の場合のみパラメータの設定などをダイアログで表示したい場合，以下のように判定することができる．
(例えば，Circleクラスの場合のみ半径を操作するエディットボックスを有効化するなど)
dynamic_castのコスト
実行コスト
プログラミングのコスト
ダウンキャストに失敗した場合はNULLが返される．これを利用して，特定の派生クラスのみに異なる処理を与えることが可能である．
例えば
class Shape; void Shape::Draw(); class Circle : public Shape; void Circle::SetRadius(const double);というクラスがあったとする．Shapeは点データを保持し，Drawで描画することができるとする．
一方，モデルとして
class Model
{
std::vector<Shape*> objects;
std::vector<Shape*>& GetObjects();
};
と，Shapeのコンテナがあるとする．(特定の図形ごとにコンテナを分けるのはナンセンス)
特定の幾何図形の場合のみパラメータの設定などをダイアログで表示したい場合，以下のように判定することができる．
(例えば，Circleクラスの場合のみ半径を操作するエディットボックスを有効化するなど)
Shape* _shape = model.GetObjects().at(idx);
if( dynamic_cast<Circle*>(_shape) != NULL )
{
//実体はCircle
m_EditRadius.EnableWindow(TRUE);
}
else
{
//実体はCircleではない．
m_EditRadius.EnableWindow(FALSE);
}
dynamic_castのコスト 
実行コスト
たしかにdynamic_castは高コストな変換と言われるがdynamic_castを使わなくとも仮想関数を呼び出す時には内部で同じRTTIに基づく変換は行われる．
その必要な時間もせいぜいstaticの数倍から数十倍であり，GUI等のイベントやその他の処理と比べると微々たるものであり，それほど考慮すべきことではないだろう．
むしろ，組み込み等，dynamic_castの実行コストが気になるのであれば，Cなどの非オブジェクト指向な言語を使用すべきである．
その必要な時間もせいぜいstaticの数倍から数十倍であり，GUI等のイベントやその他の処理と比べると微々たるものであり，それほど考慮すべきことではないだろう．
むしろ，組み込み等，dynamic_castの実行コストが気になるのであれば，Cなどの非オブジェクト指向な言語を使用すべきである．
プログラミングのコスト
もう一つ重要なコストが，いかにバグを減らし可読性・保守性のよいコーディングを行うかという点である．
若干の実行速度を犠牲にしてもそれは大きな価値がある．
その恩恵の最たるものは，新たな機能を持った派生クラスを作成した際に，それを使用するクラスの変更を要求しないことが挙げられる．
例えば図形クラスと描画クラスによるDoc-View構造のソフトウェアを考える．
初期は円と四角形のみの図形クラスであったが，新たに三角形を追加するとしよう．
その時，描画クラスにおいても複数箇所の変更・追記をしなければならないとすると，それは大きなコストと言える．
どのような図形であろうと基本クラスShapeが描画に必要な全ての情報を取得するためのインターフェイスを持っていれば，
描画クラスを変更する必要はない．
一方，各図形固有のパラメータ(半径や辺の長さ，角度など)をGUIから変更したい場合には，各派生クラス固有の関数を使うことになる．
対象が具体的に何かを知らなければどのようなパラメータが操作可能か不明であるため，dynamic_castを用いればよい．
ただし，それが本当に派生クラス固有とすべき機能であるかは十分に検討すべきである．
若干の実行速度を犠牲にしてもそれは大きな価値がある．
その恩恵の最たるものは，新たな機能を持った派生クラスを作成した際に，それを使用するクラスの変更を要求しないことが挙げられる．
例えば図形クラスと描画クラスによるDoc-View構造のソフトウェアを考える．
初期は円と四角形のみの図形クラスであったが，新たに三角形を追加するとしよう．
その時，描画クラスにおいても複数箇所の変更・追記をしなければならないとすると，それは大きなコストと言える．
どのような図形であろうと基本クラスShapeが描画に必要な全ての情報を取得するためのインターフェイスを持っていれば，
描画クラスを変更する必要はない．
一方，各図形固有のパラメータ(半径や辺の長さ，角度など)をGUIから変更したい場合には，各派生クラス固有の関数を使うことになる．
対象が具体的に何かを知らなければどのようなパラメータが操作可能か不明であるため，dynamic_castを用いればよい．
ただし，それが本当に派生クラス固有とすべき機能であるかは十分に検討すべきである．
コメントをかく