[解決済み] C++のポリモーフィズム

"ポリモーフィック"。

Alf Steinbach 氏は、C++ 標準では ポリモーフィック は仮想ディスパッチを用いた実行時ポリモーフィズムのみを指すと述べています。 一般的なComp. Sci.の意味はもっと包括的で、C++の作者であるBjarne Stroustrupの用語集( http://www.stroustrup.com/glossary.html ):

ポリモーフィズム - 異なるタイプのエンティティに単一のインターフェイスを提供すること。仮想関数は基底クラスが提供するインタフェースを通じて動的な（実行時の）ポリモーフィズムを提供します。オーバーロードされた関数とテンプレートは、静的な（コンパイル時の）ポリモーフィズムを提供します。TC++PL 12.2.6, 13.6.1, D&E 2.9に記載されています。

この回答は、質問と同様に、C++の機能をComp.Sci.の用語に関連付けます。Sci. の用語に関連しています。

ディスカッション

C++標準では、Comp. Scienceコミュニティよりも狭い範囲のポリモーフィズムの定義を使っています。Sci. コミュニティでは、以下のような相互理解を確実にするために のための相互理解を確保する必要があります。 の相互理解を確実にするために...

• 曖昧でない用語を使うこと ("can we make this code reusable for other types?" or "can we use virtual dispatch?" rather than "can we make this code polymorphic?"), および／または
• 用語の明確な定義。

それでも、優れたC++プログラマになるために欠かせないのは を理解することです。 を理解することです。

アルゴリズム的なコードを一度書いたら、それを多くの種類のデータに適用することができる

...そして、異なるポリモーフィック機構が実際のニーズにどのように合致するかをよく理解することです。

ランタイム・ポリモーフィズムが合う

• ファクトリーメソッドで処理された入力は、異種オブジェクトのコレクションとして吐き出され、そのコレクションは Base* s,
• の実装は、設定ファイル、コマンドラインスイッチ、UI設定などに基づいて実行時に選択されます。
• ステートマシンパターンのように、実行時に変化する実装。

実行時ポリモーフィズムのための明確なドライバがない場合、コンパイル時のオプションがしばしば好まれます。 考えてみてください。

• テンプレート化されたクラスのいわゆるコンパイル時の側面は、実行時に失敗するファットインターフェイスよりも望ましいです。
• SFINAE
• CRTP
• 最適化 (インライン化およびデッドコードの排除、ループのアンロール、スタックベースの静的配列とヒープを含む多くの機能)
• __FILE__ , __LINE__ や、文字列リテラルの連結など、マクロならではの機能があります（邪道ですが;-)）。
• テンプレートとマクロは意味的な使用がサポートされていることをテストしますが、サポートが提供される方法を人為的に制限しません (仮想ディスパッチが正確に一致するメンバー関数のオーバーライドを要求することによってそうなりがちなように)。

ポリモーフィズムをサポートする他のメカニズム

約束通り、完全性を期すため、いくつかの周辺トピックがカバーされています。

• コンパイラが提供するオーバーロード
• 変換子
• キャスト/強制

この回答は、上記の組み合わせがどのようにポリモーフィックコード、特にパラメトリックポリモーフィズム（テンプレートとマクロ）に力を与え、簡素化するかを議論することで締めくくられています。

型固有の操作にマッピングするためのメカニズム

暗黙のコンパイラ提供のオーバーロード

概念的には、コンパイラが オーバーロード という演算子があります。 これはユーザー指定のオーバーロードと概念的には変わりませんが、見落とされやすいのでリストアップしました。 例えば int という演算子や double は同じ記法で x += 2 とコンパイラが生成する。

• タイプ固有の CPU 命令
• 同じ型の結果

オーバーロードはその後、ユーザー定義型にもシームレスに拡張されます。

std::string x;
int y = 0;

x += 'c';
y += 'c';

コンパイラが提供する基本的な型のオーバーロードは高水準（3GL+）のコンピュータ言語では一般的であり、ポリモーフィズムの明示的な議論は一般的にそれ以上のものを意味するものである。 (2GL - アセンブリ言語 - は、しばしばプログラマが異なる型のために異なるニーモニックを明示的に使用することを要求します)。

標準的な変換

C++標準の第4章では、Standardの変換について説明されています。

最初のポイントはうまく要約されています（古い草案から - うまくいけばまだ実質的に正しい）。

-1- 標準変換は組み込み型のために定義された暗黙の変換です。conv節はそのような変換の完全なセットを列挙しています。標準変換シーケンスは，以下の順序での標準変換のシーケンスです。

• 次のセットから0または1つの変換：lvalueからrvalueへの変換、配列からポインタへの変換、関数からポインタへの変換。

• 以下のセットから0個または1個の変換：積分プロモーション、浮動小数点プロモーション、積分変換、浮動小数点変換、浮動小数点-積分変換、ポインタ変換、ポインタからメンバーへの変換、ブール値への変換。

• ゼロまたは1の資格変換。

[注意：標準的な変換シーケンスは空である、すなわち、変換なしで構成されることができます。] 標準的な変換シーケンスは，式を必要な目的型に変換するために必要であれば，式に適用されます。

これらの変換により、以下のようなコードが可能になります。

double a(double x) { return x + 2; }

a(3.14);
a(42);

先ほどのテストを適用する。

多相であるためには、[ a() ]は少なくとも2つの値を操作できなければなりません。 明確な 型(例えば int と double ), タイプに適したコードを見つけ、実行する .

a() は、それ自体が double であり、したがって ではなく ポリモーフィックではありません。

しかし、2回目の呼び出しで a() を変換するために、コンパイラは "浮動小数点プロモーション" (標準§4) のための型に適したコードを生成することを知っています。 42 に 42.0 . この余分なコードは 呼び出し 関数にあります。 このことの意義については、結論で述べます。

> 強制、キャスト、暗黙のコンストラクタ

これらのメカニズムにより、ユーザー定義クラスは組み込み型の標準変換に似た振る舞いを指定することができます。 見てみましょう。

int a, b;

if (std::cin >> a >> b)
    f(a, b);

ここでは、オブジェクト std::cin は変換演算子の助けを借りて、ブーリアンコンテキストで評価されます。 これは上のトピックのStandard conversionから"integral promotions"等と概念的にグループ化することができます。

暗黙のコンストラクタは効果的に同じことを行いますが、cast-to型によって制御されます。

f(const std::string& x);
f("hello");  // invokes `std::string::string(const char*)`

コンパイラが提供するオーバーロード、変換、強制の意味するところ

考えてみてください。

void f()
{
    typedef int Amount;
    Amount x = 13;
    x /= 2;
    std::cout << x * 1.1;
}

もし、金額を x が実数として扱われるようにしたい場合 (つまり 6 に切り捨てられるのではなく 6.5 になるように)、以下のようにします。 だけ に変更する必要があります。 typedef double Amount .

それはいいのですが、そうでなければ も を明示的にタイプ コレクトにするのは、それほど大変な作業ではありません。

void f()                               void f()
{                                      {
    typedef int Amount;                    typedef double Amount;
    Amount x = 13;                         Amount x = 13.0;
    x /= 2;                                x /= 2.0;
    std::cout << double(x) * 1.1;          std::cout << x * 1.1;
}                                      }

しかし、最初のバージョンを変換することを考えてみてください。 template :

template <typename Amount>
void f()
{
    Amount x = 13;
    x /= 2;
    std::cout << x * 1.1;
}

このようなちょっとした便利な機能により、以下のように簡単にインスタンス化できます。 int または double で、意図したとおりに動作します。 これらの機能がなければ、明示的なキャスト、型特性、および/またはポリシークラス、冗長でエラーを起こしやすい混乱が必要になるでしょう。

template <typename Amount, typename Policy>
void f()
{
    Amount x = Policy::thirteen;
    x /= static_cast<Amount>(2);
    std::cout << traits<Amount>::to_double(x) * 1.1;
}

コンパイラが提供する組み込み型の演算子オーバーロード、標準変換、キャスト/強制/暗黙のコンストラクタなど、これらはすべてポリモーフィズムの微妙なサポートに寄与しているわけです。 この回答の一番上にある定義から、それらはマッピングによって型に適したコードを見つけ、実行することに対処しています。

• パラメータ型からの "away"。

  • から ポリモーフィックなアルゴリズムコードが扱う多くのデータ型について

  • まで 同じまたは他の）型の（潜在的により少ない）数のために書かれたコード。

• 定数型の値からパラメトリック型への変換

これらは ではない 多相コンテキストを確立するものではありませんが、そのようなコンテキストの中でコードを強化・簡略化する手助けをします。

騙されたと思うかもしれません...たいしたことないように思えますが。 重要なのは、パラメトリックな多相コンテキスト (つまり、テンプレートやマクロの内部) では、任意の大きな範囲の型をサポートしようとしていますが、しばしば、小さな型のセットのために設計された他の関数、リテラル、操作の観点から、それらの操作を表現したいと思うのです。 操作や値が論理的に同じである場合に、型ごとにほぼ同じ関数やデータを作成する必要性を減らすことができるのです。 これらの機能が協調して、限られた利用可能な関数やデータを使って直感的に期待されることを行い、本当に曖昧な場合にのみエラーで停止するという、quot;best effort" という姿勢を付加しているのです。

これは、ポリモーフィック コードをサポートするポリモーフィック コードの必要性を制限し、ポリモーフィズムの使用についてより厳重な網を張って、局所的な使用が広範囲にわたる使用を強制されないようにするのに役立ちます。 C++で一般的なように、プログラマはポリモーフィズムが使用される境界を制御するために多くの自由を与えられます。