当前位置：文江博客话题详情

为什么 C++模板定义需要在标题中吗？

发布于 2024-10-20 09:23:18 字数 294 浏览 2 评论 0原文

可能的重复：
为什么应该模板类的实现和声明在同一个头文件中吗？

例如，定义模板类时，为什么类方法的实现需要位于头文件中？为什么它们不能位于实现文件（cpp/cxx）中？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

尘曦 2024-10-27 09:23:18

模板类不是一个类，它是一个可用于创建类的模板。当您实例化这样的类时，例如MyTemplate，编译器会当场创建该类。为了创建它，它必须查看所有模板化成员函数（以便它可以使用模板创建实际成员函数，例如 MyTemplate::foo() ），因此这些模板化成员函数必须位于标头中。

如果成员不在标头中，编译器将简单地假设它们存在于其他位置，并从模板化函数声明创建实际的函数声明，这会给您带来链接器错误。

“export”关键字应该可以解决这个问题，但很少有编译器支持它（我只知道 Comeau）。

您还可以显式实例化 MyTemplate - 然后编译器在编译包含 MyTemplate< 的 cpp 文件时将为 MyTemplate 创建实际的成员函数。 /code> 成员函数定义模板。

回复收藏 0 原文

往事随风而去 2024-10-27 09:23:18

它们在实例化时需要对编译器可见。这基本上意味着，如果您在标头中发布模板，并且您依赖于隐式实例化，那么包含该标头的所有翻译单元都必须可以看到定义。

如果您要显式实例化模板，则不需要在标头中定义它们，但这在大多数情况下不是一个好主意。

至于原因，基本上可以归结为这样一个事实：模板不是在编译器解析定义时编译的，而是在实例化模板时编译的，然后针对特定的实例化类型进行编译。

回复收藏 0 原文

镜花水月 2024-10-27 09:23:18

如果您的编译器支持导出，那么它就不支持。只有基于 EDG 的编译器支持导出，因此它将从 C++0x 中删除。

非导出模板要求编译器可以看到完整的模板定义，以便为您作为参数提供的特定类型实例化它。例如：

template<typename T> 
struct X {
    T t;
    X(int i): t(i) {}
};

现在，当您在某个翻译单元中编写 X(5) 时，编译器作为编译该翻译单元的一部分必须检查 X 的构造函数类型正确，为其生成代码，等等。因此它必须看到 X 的定义，以便它可以允许 X(5) 但禁止 X(5)。

确保编译器在使用它的所有翻译单元中看到相同模板定义的唯一明智方法是将定义放入头文件中。不过，就标准而言，欢迎您手动复制并粘贴它，或者在仅在该翻译单元中使用的 cpp 文件中定义模板。

export 实际上告诉编译器必须将模板定义的解析形式输出到一种特殊类型的目标文件中。然后链接器执行模板实例化。使用普通的工具链，编译器足够智能来执行模板实例化，而链接器则不然。请记住，模板实例化必须完成编译器除了基本解析之外所做的几乎所有事情。

If your compiler supports export, then it doesn't. Only EDG-based compilers support export, and it's going to be removed from C++0x because of that.

Non-exported templates require that the compiler can see the full template definition, in order to instantiate it for the particular types you supply as arguments. For example:

template<typename T> 
struct X {
    T t;
    X(int i): t(i) {}
};

Now, when you write X<float>(5) in some translation unit, the compiler as part of compiling that translation unit must check that the constructor of X is type-correct, generate the code for it, and so on. Hence it must see the definition of X, so that it can permit X<float>(5) but forbid X<char*>(5).

The only sensible way to ensure that the compiler sees the same template definition in all translation units that use it, is to put the definition in a header file. As far as the standard is concerned, though, you're welcome to copy-and-paste it manually, or to define a template in a cpp file that is used only in that one translation unit.

export in effect tells the compiler that it must output a parsed form of the template definition into a special kind of object file. Then the linker performs template instantiation. With normal toolchains, the compiler is smart enough to perform template instantiation and the linker isn't. Bear in mind that template instantiation has to do pretty much everything that the compiler does beyond basic parsing.

回复收藏 0 原文

离线来电— 2024-10-27 09:23:18

它们可以位于 CPP 文件中。

问题源于这样的事实：编译器在每个翻译单元的基础上构建模板类的特定实例化的代码（例如std::vector）。在 CPP 文件中定义函数的问题是，您需要在该 CPP 文件中定义每种可能的形式（这称为模板专业化）。

因此，对于上面示例的 int 向量，您可以使用专门化在 CPP 文件中为 int 情况定义一个函数。

例如，

template<> void std::vector< int >::push_back( int& intVal )

当然这样做可以产生针对特定情况进行优化的优势，但它确实让您了解 STL 会引入多少代码膨胀！至少所有函数都没有像某些编译器过去那样定义为内联；）

They can be in a CPP file.

The problem arises from the fact that the compiler builds the code for a specific instantiation of a template class (eg std::vector< int >) on a per translation unit basis. The problem with defining the functions in a CPP file is that you will need to define every possible form in that CPP file (this is called template specialization).

So for that int vector exampled above you could define a function in a CPP file for the int case using specialization.

e.g

template<> void std::vector< int >::push_back( int& intVal )

Of course doing this can produce the advantage of optimisation for specific cases but it does give you an idea of just how much code bloat can be introduced by STL! At least all the functions aren't defined as inline as a certain compiler used to do ;)

回复收藏 0 原文