問題タブ [explicit-instantiation]

以下のコードで：

マテリアル.h:

マテリアル.h:

confdef.h:

main.cpp

(エラーを再現する上記のコードのオンライン バージョンは次のとおりです。)

コメント行に次のコンパイル エラー メッセージが表示されます。

「MakeMaterial」の呼び出しに一致する関数がありません

私は何を間違っていますか？明示的なインスタンス化により、コンパイラが正しい関数を認識できるようになるべきではありませんか?

明示的に記述すればコードはコンパイルされますが、ここでの要点は引数からMakeMaterial<solid>推測することです。どうすればこれを達成できますか?typeConfig

特殊化された明示的にインスタンス化されたテンプレート クラスがあります。

上記のファイルは、g++ 4.9.2 でスタティック ライブラリにコンパイルされます。

a1.o には A<1>::foo() が含まれ、a2.o には A<2>::foo() が含まれていると思いますが、その逆ではありません。 .cc ファイル。

ただし、両方のオブジェクト ファイルに両方の関数が含まれていることがわかります。VS2015RC はリンカの警告も表示します。

なんで？

また、N=2 の特殊化をコメント アウトすると、明示的にインスタンス化された N=2 のケースに未解決の関数があるにもかかわらず、g++ を使用してサイレントにコンパイルされます... (VS2015RC は、「明示的なテンプレートのインスタンス化要求に対して適切な定義が提供されていません」と警告します"、 予想通り）。

明確化- 標準 (14.7.3.6) によると:

[..] クラス テンプレートのメンバーが明示的に特殊化されている場合、その特殊化は、そのような使用が発生するすべての翻訳単位で、暗黙的なインスタンス化を引き起こす特殊化の最初の使用の前に宣言されなければなりません[.]

この一節は、インスタンス化するためには特殊化の使用が必要であることを (暗黙のうちに) 述べています。

私の問題は、その翻訳単位でこの仕様が使用されていないにもかかわらず、 A<2>::foo() が a1.o で暗黙的にインスタンス化されることです。

Here's a minimal example:

This program writes 42 using g++ 4.9.2, but writes 0 using Visual Studio 2015 RC. Also, if I uncomment the explicit instantiation, VS2015RC also gives 42, which is quite interesting, as the template parameter here is different from the one used in the main function.

Is this a bug? I assume that g++ is correct, as there is a reference to b inside foo, so B's constructor should be called.

EDIT: There is a simple workaround - if there is a non-static variable in B, that is referenced in A, VS2015RC will compile correctly:

This seems to work, even though b.y, as a statement, is obviously NOP.

まあ、私は明示的なテンプレートのインスタンス化によって非常に混乱していると思います ~>_<~

1. 明示的なインスタンス化宣言は、暗黙的なインスタンス化定義を悪用できますか?
2. 明示的および暗黙的なインスタンス化定義がプログラムに存在する場合はどうなりますか? それらは最終的に1つに崩壊しますか？
3. 明示的なインスタンス化宣言は、暗黙的なインスタンス化の定義の後に配置すると効果がありますか?

また、次のコードも参照してください。

リンクエラーの原因となります

GCC 5.2 を使用しますが、clang 3.6 で正常にビルドされます。基準で正しいのはどれか。

上記のすべての質問に対する答えを論理的に推測して説明できるように、明示的なテンプレートのインスタンス化を理解するための洞察に満ちた方法があることを願っています。

明示的なインスタンス化宣言は、後続の暗黙的なインスタンス化を抑制することを知っています。しかし、明示的なインスタンス化の定義しかない場合はどうなるでしょうか? 次の暗黙的なインスタンス化も抑制しますか?

例えば：

明示的なテンプレートのインスタンス化定義は、その後の暗黙的なインスタンス化を抑制しますか? externキーワードを先頭に追加して明示的な定義を宣言にすると、暗黙的なインスタンス化が抑制されることがわかっています。

次のコードを参照してください。

GCC 5.2 は正常にコンパイルされますが、clang 3.6 では次のエラー メッセージが表示されます。

それでも、次のコードでは

GCC と clang の両方でエラーが発生しました。GCC のメッセージは次のとおりです。

そしてclang用のものは

二人の男に何が起こっているのですか？標準は、明示的なテンプレートのインスタンス化宣言の前に明示的な定義を行うことを禁止していますか? 私にはほとんど意味がありません。結局のところ、最初に定義してから宣言すると、どのような害があるのでしょうか? 非テンプレート関数の場合について考えてみてください。

私の DLL には、クラス テンプレートと、そのテンプレートのインスタンス化から派生した 2 番目のクラスがあります。両方のクラスがエクスポートされ、他の DLL で使用できるようになります。コンパイラは Visual Studio 2013 です。テンプレート コードを正確に 1 つの翻訳単位でインスタンス化する必要があるため、明示的なインスタンス化を採用しています。

DLL1 内のコードは、次のように配布されます。基本クラス テンプレート:

派生クラス:

理論的には、externステートメントは、明示的なインスタンス化が実行される BaseTemplate.cpp を除くすべての翻訳単位でのインスタンス化を防止するというものでした。ただし、次の警告が表示されます (プロジェクトではエラーとして扱われるため、ビルドが中断されます)。

externステートメントを無視して、派生クラスのエクスポートがインスタンス化をトリガーするようです。派生クラスからエクスポート マクロを削除すると、DLL1 は警告なしでコンパイルされます (ただし、他の DLL は明らかにリンクに失敗します)。継承するのではなく、Derived クラスで BaseTemplate 型のメンバーを集約すると、(エクスポートを使用しても) 同様に機能します。

明示的なテンプレートのインスタンス化とエクスポートされた派生クラスを Visual Studio で組み合わせるにはどうすればよいですか?