オーバーロード | Programming Place Plus　新C++編

共通コードを constメンバ関数に書く

共通の関数を作るのではなく、constメンバ関数版のほうに目的のコードを書いて、非constメンバ関数版ではそれを強引に呼び出すというものです。

class C {
public:
    inline Data& get_data()
    {
        // constメンバ関数版を呼び出し、戻り値の const を外して返す。
        return const_cast<Data&>(static_cast<const C*>(this)->get_data());
    }
    const Data& get_data() const
    {
        return /* 複雑なコード */;
    }
};

非constメンバ関数版がやっていることはこうです。

1. *this を constオブジェクトにするため、static_cast で this を constポインタにする
2. 1 で得たポインタを使って同名のメンバ関数を呼ぶことで、constメンバ関数版を呼び出す
3. 返された結果（const Data&）から const を取り外すため、const_cast を行う
4. 3 で得た結果を返す

非constメンバ関数版の本体では、thisポインタは C* という型ですから、そのまま get_dataメンバ関数を呼び出すと、自分自身を呼び出す結果になってしまいます。constメンバ関数版を呼び出すには、強引に自分自身を const にしてしまえばよく、そのために this を const C* にキャストしています（*this を const C& にすることでも可能です）。このキャストは static_cast で行えます（このあと登場する const_cast でも可能）。

constメンバ関数が返す結果は const が付加された const Data& という型ですから、非constメンバ関数が返したい Data& にするためには const を取り外す必要があります。参照やポインタの const は const_cast で取り外せます。const_cast の文法は static_cast や reinterpret_cast（「配列とポインタ」のページを参照）と同様です。

const_cast<型>(式)

const_cast は、参照やポインタについている const や volatile（未解説）を取り外したり、付加したりできます。これ以外の場面で登場する const を操作することはできません。

const を取り外してしまうことに不安を感じるかもしれません。実際、const_cast は基本的には避けるべきものです。const を外すことは、コンパイラのチェックを黙らせているだけであって、指し示しているオブジェクトを書き換えることが安全である保証はありません。

今回の使い方の場合は、非constメンバ関数版を呼び出すことからスタートしているので、このオブジェクトが書き換えられる可能性は想定内といえます。そのため、この使い方は基本的に安全です。

const_cast を使うほかの場面として、関数内で書き換えないのにも関わらず、仮引数のポインタに const が付加されていない関数（しかも修正することもできない）を呼び出すときが挙げられます。たとえばＣ言語の文字列リテラルの型は char[] であるため、文字列を受け取る仮引数に const が付いていないことがあります。そのような関数を C++ に持ち込むと、C++ の文字列リテラルは const char[] であるため、const を外さなければ渡すことができません。

共通コードをメンバ関数テンプレートに書く

もう１つの方法は、メンバ関数テンプレート（「関数テンプレート」のページを参照）にコードを共通化する方法です³。

class C {
public:
    struct Data {
        int a;
        int b;
        int c;
    };

    inline Data& get_data()
    {
        return common_get_data(this);
    }

    inline const Data& get_data() const
    {
        return common_get_data(this);
    }

private:
    Data m_data;

private:
    template <typename T>
    static auto& common_get_data(T* self)
    {
        return self->m_data;
    }
};

common_get_dataメンバ関数テンプレートにコードを抜き出しています。

まず、このメンバ関数テンプレートは静的メンバ関数にしておかなければなりません。静的メンバ関数はクラスに結びついた存在であり、特定のオブジェクトとは無関係であるため、thisポインタとの関係性がありません（「静的メンバ」のページを参照）。したがって、呼び出し元が constメンバ関数（thisポインタが constポインタ）でも、非constメンバ関数（thisポインタが非constポインタ）でも問題なく呼び出せます。

しかし静的メンバ関数になってしまうと、thisポインタが使えないがために、データメンバにアクセスできなくなってしまいます。そこで、引数で thisポインタを渡してやればいいですが、ここでも thisポインタの const の有無が問題になります。仮引数を T* にすることで、const の有無の判断をテンプレート実引数推論（「関数テンプレート」のページを参照）に任せることで回避できます。

さらに戻り値の型を auto& にすることで、戻り値の型は return self->m_data; の結果の型になります（「関数から値を返す」のページを参照）。self の型が C* と判断されたのなら Data& ですし、const C* と判断されたのなら const Data& となります。

こうして const_cast を行うことなく、テンプレートと auto による自動的な型推論の中に const の有無の判断を隠して、constメンバ関数と非constメンバ関数のコードの共通化を図れます。

名前探索を行い、候補関数をつくる

名前探索 (name lookup) は、ソースコード上で使用されている名前が、実際には何を意味したものなのかを決定することをいいます。名前探索自体も相当に複雑なので⁵、これについても概要だけ示すことにします。

名前探索のルールは、スコープ解決演算子(::) による修飾を行っているかどうかによって異なります。

スコープ解決演算子で修飾されている名前に対する名前探索は、修飾の名前探索 (qualified name lookup) と呼ばれます。この場合、:: の左側に記述したクラス、名前空間、scoped enum から該当する名前を探索します。:: の左側に何もない場合はグローバル名前空間から探索します。

スコープ解決演算子で修飾されていない名前に対する名前探索は、非修飾の名前探索 (unqualified name lookup) と呼ばれます。この場合、その名前が使われている場所から発見できる名前を探索します。usingディレクティブ（「スコープと名前空間」のページを参照）や using宣言（「スコープと名前空間」のページを参照）の効力の影響を受けます。

非修飾の名前探索には、実引数依存の名前探索（ADL） (Argument Dependent name Lookup) と呼ばれる更なるルールが存在します⁶。これは、関数呼び出しの際、該当する関数を探すときに、実引数で指定した内容も考慮に加えるというものです。たとえば、f(T x); のように関数f を呼び出すとき、この呼び出しが記述されている場所から見えている f だけでなく、実引数の x の型が所属している名前空間も探索範囲に加えるということです。

namespace n1 {
    struct T {
        int a;
        int b;
    };
    void f(T x);
}

namespace n2 {
    void g()
    {
        n1::T x {};
        f(x);  // OK. x が n1::T であることから、n1 も探索し、n1::f を見つける
    }
}

こうした名前探索を行った結果、いくつかの関数や関数テンプレートを見つける可能性があります。これらの関数のことを候補関数 (candidate functions) と呼びます。

候補関数は名前の一致は確認されていますが、その関数が呼び出し可能であるかどうかを考慮していません。たとえば、以下のような関数であっても候補関数には選ばれます。

• 実引数と仮引数の対応が取れていない
• 宣言はあるが、定義が存在していない
• アクセス指定子の影響でアクセスできない
• =delete で削除された関数である（「静的メンバ」のページを参照）

候補関数を１つ以上発見できた場合は、候補関数を絞り込むステップへ進みます。候補関数が１つも発見できなければ、使おうとしている名前が何であるのか決定できないため、コンパイルエラーとなります。

候補関数を絞り込む 🔗

候補関数の中から、実際に呼び出せる関数、つまり適切関数 (viable functions) を絞り込みます⁷。

「viable functions」をうまく日本語訳することが難しいため、適切関数、有効な関数、妥当な関数などさまざまな訳語があります。

まず、仮引数の個数に対して、実引数の個数が十分であるかを調べます。その結果、以下のいずれかを満たしていれば、次の判断に進むことができます。満たさなければ適切関数ではありません。

• 個数が一致している
• 実引数のほうが多いが、仮引数には ... がある（... については未解説）
• 実引数のほうが少ないが、実引数より多い部分の仮引数にデフォルト実引数がある

【Ｃ言語プログラマー】... は printf関数などでおなじみの可変個引数のことです。

次に、実引数が、対応する仮引数の型と一致する、あるいは暗黙に型変換できるかどうかを調べます。型を一致させられるのであれば適切関数とみなされ、そうでなければ適切関数ではありません。

適切関数が１つだけであれば、その関数がオーバーロード解決の結果となります。複数の適切関数が残った場合は次のステップへ進んで１つに定めます。適切関数がなければコンパイルエラーです。

最適関数を決定する 🔗

適切関数の中から、最もふさわしい関数を１つに定めます。ここで選ばれる関数を、最適関数 (best viable functions) と呼びます⁸。

「best viable functions」もうまく日本語訳することが難しいですが、適切関数のうち最もふさわしい関数ということで、ここでは最適関数としています。

基本的な考え方としては、実引数の型が、仮引数の型にどれだけ近いかを比較し、最も近しい関数が選び出されるということです。引数が複数あることもありますから、第１引数なら一方の関数のほうが近くても、第２引数では他方の関数のほうが近くて、同点と言わざるをえない場合もあります。そのような場合、最適関数が１つに定めきれず、曖昧であるという主旨のコンパイルエラーになります。

型が完全に一致していれば、もっとも近いといえます。

void f(int a, int b);
void f(int a, double b);

f(100, 0);  // f(int, int) と完全一致。これが選ばれる

暗黙の型変換の内容が同じであるなら、それが必要な引数が少ない方が近いといえます。

void f(int a, int b, long c);
void f(int a, long b, long c);

f(0, 0, 0);  // f(int, int, long) は int -> long の型変換が１つだけ必要。これが選ばれる
             // f(int, long, long) は int -> long の型変換が２つ必要。

この例で、２つ目の関数f の第３引数が int であったら、暗黙の型変換が必要な個数が同じになるため、どちらがより一致しているとはいえず、コンパイルエラーになります。

void f(int a, int b, long c);
void f(int a, long b, int c);

f(0, 0, 0);  // f(int, int, long) も f(int, long, int) も、
             // int -> long の型変換が２つ必要なため曖昧である

通常の関数と、関数テンプレートがある場合、通常の関数のほうがより近いといえます。

void f(int a, int b);

template <typename T>
void f(T a, T b);

f(100, 0);     // 関数テンプレートの f にも一致するが、通常の関数である f(int, int) が選ばれる
f(12.5, 15.5); // 関数テンプレートの f が選ばれる

また、暗黙の型変換は以下のように分類できます。

1. 標準の型変換
2. ユーザー定義の型変換
3. エリプシス変換

上にあるものほど優先されます。つまり上にある型変換を使っているもののほうが、より近しい関数であると判定されます。

標準の型変換 (standard conversion) は、C++ の標準機能として備わっている暗黙の型変換のことです⁹。たとえば以下のような変換が標準の型変換です。

• 整数拡張（「整数型」のページを参照）
• 整数型どうしの変換
• 整数型と浮動小数点型との変換
• 配列からポインタへの変換（「配列」のページを参照）
• 関数から関数ポインタへの変換（「関数ポインタとラムダ式」のページを参照）
• ポインタから CV修飾子が付いたポインタへの変換（「配列とポインタ」のページを参照）

ユーザー定義の型変換 (user-defined conversion) は、プログラマーが明示的に定義した型変換のことです。変換コンストラクタ（「コンストラクタ」のページを参照）や、変換関数（未解説）が該当します¹⁰。

エリプシス変換 (ellipsis conversion) は、仮引数が ... となっている場合に行われる型変換のことです。この機能は未解説です。

問題１　（確認★）

次の関数 f1～f8 で、オーバーロードが成功するものとエラーになるものを分けてください。

void f1();
void f1(int a, int b);

int f2(int a);
double f2(int a);

int f3(int a, int b = 0);
int f3(int a = 0, int b = 0);

int f4(int a, int b);
template <typename T>
int f4(T a, T b);

template <typename T>
T f5();
template <typename T>
T f5(T a, T b);

class C1 {
public:
    int f6();
    int f6() const;
};

class C2 {
public:
    int f7();
    static int f7(int a);
};

class C3 {
public:
    int f8();

private:
    int f8(int a, int b);
};

⇒解答・解説

問題２　（基本★）

以下の関数f の呼び出しが、それぞれ異なる関数を呼び出すように関数f のオーバーロードを作成してください。また、これら以外の型の実引数を渡した場合に呼び出される関数テンプレートf も作成してください。

int main()
{
    int a {100};
    short b {200};
    double c {15.5};

    f(a);
    f(b);
    f(c);
    f(nullptr);
}

⇒解答・解説

問題３　（応用★★）

RingBufferクラステンプレートの実装でも、frontメンバ関数と backメンバ関数が、メンバ関数と constメンバ関数の違いによってオーバーロードされています。本体のコードをメンバ関数テンプレートを使って共通化してください。

現状の RingBufferクラステンプレートの実装は、「関数テンプレート」のページにあります。

⇒解答・解説

⇒解答・解説ページの先頭