デフォルトテンプレート引数を使った関数テンプレートオーバーロード解決の仕組みが分からないです

デフォルトテンプレート引数を持つ関数テンプレートのオーバーロード解決の仕組みが分からないです。

以下コードで
template <class T, typename enable_if<is_class<T>>::type>
という形ではなく、
template <class T, typename enable_if<is_class<T>>::type = nullptr>*
とするのはインスタンス化前のシグニチャが異なる型であれば、それらの関数は異なるシグニチャとみなされるからオーバーロードできると本には記述されているのですが、意味が分からないです。

なぜnullptrを仮引数にいれただけで2つの関数のシグニチャが異なる型とみなされるのでしょうか？(それともデフォルトテンプレート引数を入れたから関数のシグニチャが異なる型とみなされた？どっちなんでしょうか)
これってデフォルトテンプレート引数いれることによって関数の引数が1つになったり2つになったりするからってことなんでしょうか？
でも通常の関数はデフォルト引数の違いでオーバーロードは発生しないですよね。
テンプレートの時は特別とか？
分かんないです。

お力添えお願いいたします。

struct is_class_impl {
     template <class T>
     static std::true_type check(int T::*) {};
     template <class T>
     static std::false_type check(...) {};
 };
 template <class T>
 struct is_class : public decltype(is_class_impl::check<T>(nullptr)) {};

 template <class T, typename enable_if<is_class<T>>::type* = nullptr>
 void check(T value)
 {
     std::cout << "1" << std::endl;
 }

 template <class T, typename disable_if<is_class<T>>::type* = nullptr>
 void check(T value)
 {
     std::cout << "2" << std::endl;
 }

行動規範の内容に同意します

回答2件

こんにちは。

既に解決していますが、ちょっとだけ補足です。

インスタンス化前のシグニチャが異なる型であれば、それらの関数は異なるシグニチャとみなされるからオーバーロードできると本には記述されている

「インスタンス化前のシグニチャ」が何を指すのか分からないと思いませんか？
インスタンス化前のものはテンプレートを指していると思いますがテンプレートにシグニチャがあるとは聞いたことはないです。正直どのようなものか想像することも難しいように感じます。（雰囲気はなんとなくわかりますが、このケースでは雰囲気では足りないと思います。）

さて、このような文脈でシグニチャといえば、通常は関数のシグニチャを指します。実体化した関数テンプレートはほぼ通常の関数と同じものですので、「実体化後のシグニチャ」は理解できます。

実引数を与えて型推論してインスタンス化を試みることで関数のシグニチャを確定できます。それらのシグニチャ群から適切なものを選択すると理解した方が分かりやすいと思います。（「実体化前のシグニチャ」などという曖昧な概念を導入しないので。）

【補足の補足】
ところで、上記の過程で特定のインスタンス化がエラーになる場合、コンパイル・エラーになるのではなく、オーバーロード解決の候補から外されるというのがSFINAEです。
そして、これは通常関数同士のオーバーロード解決と同じと思います。SFINAEはテンプレート特有であるかのように説明されることが多いですが、そのため却って分かりにくくなっている気がします。

通常関数のオーバーロードを解決する際も採用されないオーバーロード関数の中には当該実引数を渡すとエラーになるものもありますね。それは単にオーバーロードの候補から外されるだけです。

C++
1#include <iostream>
2
3void foo(int)  { std::cout << "foo(int)\n"; }  // これがないとエラーになる。至極、当たり前。
4void foo(int*) { std::cout << "foo(int*)\n"; }
5
6int main()
7{
8    foo(123);
9}

wandbox

関数テンプレートのオーバーロード解決で難しい部分は、型推論とオーバーロード解決の優先順位の定義が超複雑なことです。とても覚えることはできないので、規格の狙いを把握して細かい部分はコンパイラに任せるしかないと思います。

【補足の補足の補足】
ちなみに、クラス・テンプレートの部分的特殊化や明示的特殊化も同じ名前で異なるものを定義するオーバーロードの一種です。（そのように呼んでいる人をほとんど見かけないですが。）
SFINAEはクラス・テンプレートを実体化する際にも適用されます。
当該実テンプレート引数を与えるとエラーになる部分特殊化や明示的特殊化はオーバーロードの候補から外されます。（クラスには関数のような実引数がないのでちょっと違いますが、狙いは同じと思います。）

クラス・テンプレートの実体化に型推論や優先順位は（C++14以前は）なかったので、関数テンプレートのような複雑さはないです。その分不便でした。
C++17でクラス・テンプレートにも型推論を適用できるようになり、便利になりました。その分、複雑になったようです。

投稿2019/01/30 03:44

編集2019/01/30 03:47

Chironian

総合スコア23272

mmmisaki

2019/01/30 10:31

なるほど！分かりやすいです！ありがとうございます！

行動規範の内容に同意します

ベストアンサー

インスタンス化前のシグニチャが異なる型であれば、それらの関数は異なるシグニチャとみなされるからオーバーロードできる

これはSFINAEそのものの説明ですかね。enable_ifを使う理由でして、デフォルト引数nullptrの説明ではないです。

デフォルト引数を使わない場合、呼び出すときにtemplate実引数をすべて指定しなければならず、非常に面倒です。

なのでデフォルト引数を利用しているに過ぎません。

話がそれますが、disable_ifは標準にないのでわざわざ定義する必要があり、めんｄなので普通は条件式をひっくり返すか、C++17で追加されたstd::negationを使うように思います。

またstd::enable_ifの使い方ですが、
std::enable_ifを使ってオーバーロードする時、enablerを使う？
に紹介のあるように

cpp
1template <class T, std::enable_if_t<std::is_class_v<T>, std::nullptr_t> = nullptr>
2void check(T value)
3{
4    std::cout << "1" << std::endl;
5}
6template <class T, std::enable_if_t<!std::is_class_v<T>, std::nullptr_t> = nullptr>
7void check(T value)
8{
9    std::cout << "2" << std::endl;
10}

のように使うことが多いです。

もっともC++17で追加されたif constexpr文を使って

cpp
1template <class T>
2void check(T value)
3{
4    if constexpr(std::is_class_v<T>){
5        std::cout << "1" << std::endl;
6    }
7    else {
8        std::cout << "2" << std::endl;
9    }
10}