Question

我并不完全清楚新的extern template功能如何在C ++ 11中运行。据我所知，它旨在帮助加快编译时间，并简化与共享库的链接问题。这是否意味着编译器甚至不解析函数体，强制进行非内联调用？或者它是否只是指示编译器在进行非内联调用时不生成实际的方法体？显然，链接时代码生成无法承受。

作为差异可能重要的具体示例，请考虑对不完整类型进行操作的函数。

//Common header
template<typename T>
void DeleteMe(T* t) {
    delete t;
}

struct Incomplete;
extern template void DeleteMe(Incomplete*);

//Implementation file 1
#include common_header
struct Incomplete { };
template void DeleteMe(Incomplete*);

//Implementation file 2
#include common_header
int main() {
   Incomplete* p = factory_function_not_shown();
   DeleteMe(p);
}

在“实施文件2”中，delete指向Incomplete的指针是不安全的。因此，DeleteMe的内联版本将失败。但是如果它被保留为实际的函数调用，并且函数本身是在“实现文件1”中生成的，那么一切都将正常工作。

作为推论，对于具有类似extern template class声明的模板化类的成员函数，规则是否相同？

出于实验目的，MSVC会为上述代码生成正确的输出，但如果删除extern行，则会生成有关删除不完整类型的警告。然而，这是他们多年前推出的非标准扩展的残余，所以我不确定我能相信这种行为有多少。我没有访问任何其他构建环境来进行实验[save ideone et al，但仅限于一个翻译单元在这种情况下是相当有限的]。

Answer 1

extern模板背后的想法是使显式模板实例化更有用。

如您所知，在C ++ 03中，您可以使用以下语法显式实例化模板：

template class SomeTemplateClass<int>;
template void foo<bool>();

这告诉编译器在当前翻译单元中实例化模板。但是，这并不会阻止隐式实例化的发生：编译器仍然必须执行所有隐式实例化，然后在链接期间将它们再次合并在一起。

示例：

// a.h
template <typename> void foo() { /* ... */ }

// a.cpp
#include "a.h"
template void foo<int>();

// b.cpp
#include "a.h"
int main()
{
    foo<int>();
    return 0;
}

此处，a.cpp显式实例化foo<int>()，但是一旦我们编译b.cpp，它将再次实例化它，因为b.cpp不知道a.cpp无论如何都要实例化它。对于具有许多不同翻译单元进行隐式实例化的大型函数，这可以极大地增加编译和链接时间。它还可能导致函数被不必要地内联，这可能导致严重的代码膨胀。

使用extern模板，您可以让其他源文件知道您计划明确地实例化模板：

// a.h
template <typename> void foo() { /* ... */ }
extern template void foo<int>();

这样，b.cpp不会导致foo<int>()的实例化。该函数将在a.cpp中实例化，并将像任何普通函数一样链接。它内联的可能性也小得多。

请注意，这不会阻止内联 - 该函数仍然可以在链接时内联，其方式与仍然可以内联普通非内联函数的方式完全相同。

编辑：对于那些好奇的人，我只是做了一个快速测试，看看g ++花了多少时间来实例化模板。我尝试在不同数量的翻译单元中实例化std::sort<int*>，有或没有实例化被抑制。结果是结论性的：每次实例化std :: sort 30ms。绝对有时间在一个大型项目中保存。

Answer 2

使用extern template class似乎不会阻止内联。我将通过一个例子来说明这一点，它有点涉及但最简单的我可以想出来。

在文件a.h中，我们定义了模板类CFoo，

#ifndef A_H
#define A_H
#include <iostream>

template <typename T> class CFoo{
  public: CFoo(){
      std::cout << "CFoo Constructor, edit 0" << std::endl;
    }
};

extern template class CFoo<int>;
#endif

在a.h的末尾，我们使用extern template class CFoo<int>向#include a.h的任何翻译单元表明它不需要为CFoo生成任何代码。这是我们承诺CFoo将顺利链接的所有事情。

我们有文件c.cpp，

#include "a.h"

void run(){
  CFoo<int> cf;
}

由于extern template class promise' at the end of a.h, the translation unit of c.cpp does not需要'为类CFoo生成任何代码。

最后我们在b.cpp中声明一个main函数，

void run();
int main(){
  run();
  return 0;
}

b.cpp中没有任何花哨的东西，我们只是声明void run()，它将链接到链接时翻译单元b.cpp的实现。为完整起见，这是一个makefile

cflags = -std=c++11 -O1

b : b.o a.o c.o
  g++ ${cflags} b.o a.o c.o -o b

b.o : b.cpp 
  g++ ${cflags} -c b.cpp -o b.o

c.o : c.cpp 
  g++ ${cflags} -c c.cpp -o c.o

a.o : a.cpp a.h
  g++ ${cflags} -c a.cpp -o a.o

clean:
  rm -rf a.o b.o c.o b

使用此makefile编译并链接可执行文件 a ，在运行时输出``CFoo Constructor，编辑0''。但请注意！在上面的示例中，我们似乎没有在任何地方声明CFoo<int>：CFoo<int>肯定没有在翻译单元b.cpp上声明，因为标题没有出现在该翻译单元上，而翻译单元c.cpp被告知它不需要实施CFoo。那是怎么回事？

对makefile进行一次更改：将-O1替换为-O0，并使make clean

现在，链接调用导致错误（使用gcc 4.8.4）

c.o: In function `run()':
c.cpp:(.text+0x10): undefined reference to `CFoo<int>::CFoo()'

如果首先没有内联，这是我们所期望的错误。至少这是我得出的结论，非常欢迎进一步的想法。

要获得与-O1的链接，我们需要遵守我们的承诺并提供CFoo的实现，我们在文件中提供了a.cpp

#include "a.h"
template void foo<int>();

我们现在可以保证CFoo出现在a.cpp的翻译单元上，我们的承诺将被保留。顺便说一句，请注意a.cpp中的template void foo<int>()前面有extern template void foo<int>()，但是包含了a.h，这没有问题。

最后，我发现这种不可预测的优化依赖行为令人讨厌，因为这意味着如果没有内联（尝试更改标准输出），对{ah}的修改和a.cpp的重新编译可能不会如预期那样反映在run()中Foo构造函数和翻拍）。

Answer 3

这是一个有趣的例子：

#include <algorithm>
#include <string>

extern template class std::basic_string<char>;
int foo(std::string s)
{
    int res = s.length();
    res += s.find("some substring");
    return res;
}

当使用g ++ - 7.2在-O3编译时，这会产生对string :: find的非内联调用，但是对string :: size进行内联调用。

虽然没有extern模板，但确实内联了所有内容。 Clang具有相同的行为，MSVC几乎无法在任何情况下内联任何内容。

所以anwser是：它取决于，编译器可能有特殊的启发式。

外部模板是否阻止函数内联？

3 个答案: