extern template是否阻止函数内联?

Does extern template prevent inlining of functions?

本文关键字：函数 template 是否 extern      更新时间：2023-10-16

我不完全清楚新的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等，但在这种情况下，被限制在一个翻译单元是相当有限的]。

外部模板背后的思想是使显式模板实例化更有用。

如您所知，在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无论如何都会实例化它。对于具有许多不同翻译单元进行隐式实例化的大型函数，这可能会大大增加编译和链接时间。它还可能导致函数不必要地内联，从而导致严重的代码膨胀。

使用外部模板，您可以让其他源文件知道您计划显式地实例化模板:

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

这样，b.cpp就不会引起foo<int>()的实例化。该函数将在a.cpp中实例化，并将像任何普通函数一样进行链接。它也不太可能被内联。

注意，这并不能阻止内联——函数仍然可以在链接时被内联，就像普通的非内联函数一样。

编辑:对于那些好奇的人，我刚刚做了一个快速测试，看看g++实例化模板花费了多少时间。我尝试在不同数量的翻译单元中实例化std::sort<int*>，无论实例化是否被抑制。结果是确凿的:每次实例化std::sort 30ms。

使用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生成任何代码。这是我们做出的承诺，所有的东西都将顺利连接。

在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.cp中声明了一个main函数， 
void run();
int main(){
  run();
  return 0;
}

在b.cp中没有什么特别的，我们简单地声明void run()，它将在链接时链接到翻译单元b.cp的实现。为了完整起见，这里有一个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, edit 0''。但是请注意!在上面的例子中，我们似乎没有在任何地方声明CFoo<int>: CFoo<int>肯定没有在翻译单元b.cpp上声明，因为头文件没有出现在翻译单元b.cpp上，并且翻译单元c.cpp被告知它不需要实现CFoo。那么这是怎么回事呢?

对makefile做一个修改:用- 0替换- 01，并清空Make

现在，链接调用导致错误(使用gcc 4.8.4)

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

如果一开始就没有内联，这是我们所期望的错误。至少这是我得出的结论，欢迎提出进一步的意见。

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

中提供了这一点
#include "a.h"
template void foo<int>();

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

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

下面是一个有趣的例子:

#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的内联调用。

虽然没有外部模板，但所有内容都是内联的。Clang有相同的行为，MSVC几乎无法在任何情况下内联任何东西。

所以答案是:视情况而定，编译器可能对此有特殊的启发。

相关文章：