问题标签 [explicit-instantiation]

在尝试将具有显式实例化函数模板的类引用到另一个 Visual Studio 2013 项目时，我遇到了 LNK2019 链接器错误。

显式实例化在同一个项目 (project1) 中工作。但是，一旦我尝试从另一个项目（project2）引用 project1 中的函数模板，我就会得到 LNK2019 错误链接器。

我在两个项目中都使用了 __cdecl 调用约定（/Gd 标志）。

项目一：

项目二：

我得到的错误是：

我有几个带有模板化成员函数的类和一个预定义的类型列表，它们将与它们一起使用（Wandbox 链接：

键入要实例化的成员函数和类型的每个组合，但它有几个缺点：

• 这很乏味
• 必须输入每个参数的整个函数签名，并且
• 必须在几个地方进行功能签名更改
• 必须为每个成员函数添加一个类型到列表中

我上面的解决方法适用于我测试过的大多数旧编译器（C++03 兼容性将是一个巨大的优势），但我不确定是否允许智能编译器删除未使用的参数和函数实例化。

对于常规函数，有一些解决方法，但据我了解，它们不适用于成员函数。

如何更改我的instantiate函数以接受成员函数和附加参数？

这个问题是在这个答案的背景下出现的。

正如我所料，这个翻译单元不能编译：

我理解这一点，我曾尝试两次进行相同的显式模板实例化。然而，事实证明，将其分成不同的单元，它编译：

我没想到会这样。我假设具有相同参数的多个显式模板实例化会破坏 ODR，但似乎并非如此。然而，这确实失败了：

用户Oliv帮助我指出了标准中的相关段落，但我仍然对此感到有些困惑，所以我希望有人可以用更简单的术语解释这背后的逻辑（例如，什么应该或不应该被认为是破坏 ODR以及为什么我的期望是错误的）。

编辑：

再举一个例子，这是一个分为两个单元的程序，可以正确编译，但会产生令人惊讶的结果：

输出：

在这种情况下，删除显式模板实例化会产生0. 我知道拥有两个具有不同定义的模板并不是一个常见的用例，但我认为 ODR 是为了避免此类问题而精确实施的。

我有一个带有模板方法的类，该方法在标头中声明并在 cpp 文件中定义，所以

接着

现在，在其他地方，在测试中，我有

并且由于我明确地实例化了int模板参数的函数，所以一切都很好。或者应该是！

我的代码与 GCC 7.3.0 链接良好，但无法与 clang 6 链接，后者报告了对 function 的未定义引用fun。

这里发生了什么？还有什么需要我注意的吗？也许是 GCC 认为理所当然而 clang 没有的东西？

谢谢！

编辑

@WhozCraig、@Neil Butterworth 这里是两个工具链的链接命令。

海合会：

铛：

@IdeaHat：不幸的是，这并没有解决问题，我仍然遇到同样的错误

编辑 2 由于我实际尝试编译的代码 [显然] 不是那个，所以我尝试编译这个 MWE，GCC 和 clang 都用cc A.cpp main.cpp.

我现在正试图了解这个最小案例和我实际拥有的代码之间的区别。

以下代码（我无法制作更短的 MVCE）

单位.h：

单位.cc：

主.cc：

无法在 clang 下编译（Apple LLVM 版本 9.0.0 (clang-900.0.39.2) -哪个 llvm 版本？），结果：

gcc（8.2.0）一切正常。经检查，gcc 似乎发出foo<int>::foo(foo<int>&&)in main.o，而 clang 未能完全发出它。

正确的行为是什么：移动构造函数应该用ordefault发出吗？这是一个已知的clang错误吗？unit.omain.o

有用的链接：https ://en.cppreference.com/w/cpp/language/class_template

编辑：这不是链接问题的重复，因为我正在使用显式实例化并且只有特定类型的成员函数不链接（其他人这样做）。

以下代码编译但不链接，我不明白为什么。它显式地实例化Vector类以限制可能参数的数量T，因此隐藏Vector<T>.cpp 文件中的定义。

我得到的错误是：

我在VS 15.9.4中使用VC++ 17进行编译。

请注意，对Vector<int>不是函数模板的成员的调用确实可以正常链接。

如果我有一个带有重载模板成员函数（使用 SFINAE）的模板类，例如：

现在在我的 CPP 文件中，我必须定义并显式实例化：

按类型进行分组实例化有哪些不同的可能方法 - 例如：

鉴于我必须使用 C++14，我可以提出 2 个解决方法，但不想/不喜欢：
1. Macros：可能，但想强烈避免。
2. Definition in header, no explicit instantiation needed：可能，但我正在处理一个巨大的存储库，其中我处理的文件几乎无处不在 - 所以如果我走这条路线进行微小的更改，我的构建时间会很长。

链接到代码片段

我对 C++ 模板没有太多经验，所以我的术语可能不正确。请多多包涵，欢迎指正。

我有通用类型fixed_buf<N>：

我想定义一个通用to_hex函数

使用显式实例化我也有以下内容：

我应该如何显式实例to_hex化fixed_buf<N>？可能吗？

注意：这个问题是关于显式实例化，而不是显式特化。

请看以下示例：

假设我最初的目标是仅显式实例化第二个函数模板，A = true因此我编写了 line // 3。然而直观地，第一个定义也可以用 line 显式实例化，// 3这有点问题，因为我实际上无法用当前语法转义它，因为bool A在我的情况下无法推断。从理论上讲，如果两个函数模板最终都被显式实例化，我什至不介意，但最有趣的部分是实际的编译结果。

（在所有编译成功的情况下，只有第二个函数模板被实例化。）

1. 原案。msvc用和编译clang。编译失败gcc：

   错误：'void f(int&)' 的模版特化 'f' 模棱两可

2. 在第一个函数模板中替换bool A为bool A = true使 gcc 编译它。

3. 替换X &x为X &&x(forwarding reference) 会使 clang 无法编译它：

   错误：“f”的显式实例化的部分排序不明确

这是最激烈案例的演示。

（使用了 Godbolt 上可用的编译器的最新版本）

所以我的问题是——这种情况下的显式实例化行为是否真的被指定得如此微弱，以至于很容易进入这种雷区，或者可能msvc是最符合标准的？就个人而言，我不觉得我最初的目标是超凡脱俗，即使与当前的语法有点冲突。

我正在阅读类型擦除：

Andrzej 的 C++ 博客类型擦除 — 第一部分

我在哪里遇到以下文字：

除非您可以提前枚举模板的所有实例，否则您必须在头文件中包含每个函数模板的主体，您不能将声明与实现分开

枚举模板的所有实例化是否与回答以下问题时指出的显式实例化相同？

为什么模板只能在头文件中实现？

另一种解决方案是保持实现分离，并显式实例化您需要的所有模板实例：