我想知道是否使用模板，在其他线程中我发现由于某些原因必须在头文件中实现模板。没关系，我的问题是如果其他程序使用它，是否需要源？从其他线程答案的逻辑来看，似乎即使是其他程序也需要完整的实现，因此编译器可以判断一行是否可以使用模板化函数。
如果是的话，我想模板对于希望其他人使用他的库的开发人员来说不是一件好事？如果没有，那么我们很好，将使用模板。
或者至少有什么办法可以节省我的辛苦、花费的时间和其他人的代码？
（我将使用 stl 向量等，但我要求我自己的代码......模板似乎很好，为您节省大量硬编码行或宏滥用，但如果其他人可以阅读您的源代码，那几乎没有任何意义[打开项目很有意义 xD])
谢谢，乔
如果您希望您的图书馆的用户能够使用您的模板，那么他们的源代码需要对这些用户可用。
但是，您有时可以设计模板类，以便大多数逻辑发生在标头中没有完整源代码的非模板类中。
这取决于您的模板是库接口的一部分还是只是实现的一部分。
如果它们是接口的一部分（即，入口点可能返回特定模板类型的对象），那么是的，您需要将模板定义暴露给外界。
但是如果模板只是你实现的一部分，那么一旦你构建了你的库，就没有必要与你的库的使用者共享模板定义。
您可以将模板编写为非模板（通常是非类型安全）代码的包装器。
优点是...
明显的缺点是您有额外的抽象层和开销，并且非类型安全的实现代码显然需要小心。我倾向于在非模板代码中定义一个抽象的“工具”类，专门用于模板包装器。我称它为工具是因为方法主要不是作用于工具状态，而是作用于作为 void* 参数传入的对象。工具类将大多数类型不安全问题封装在几个方法中。该模板还提供了用户实际使用的类型安全包装器，它与不安全代码接口，提供工具实例并进行类型转换等。
例如，如果我正在实现一个树数据结构，大多数树算法将是类型不安全的，并且会将节点和数据项视为 void* 指针（或者可能是 node* 和 data* 指针，其中声明了节点和数据但未定义的结构）。我将有一个抽象的树工具库，其中包含用于节点创建、处置和其他基本操作的纯方法，包装器模板将基本上专门化树工具，提供知道节点和数据项的精确类型的方法实现，并持有该工具的一个实例作为类成员。对用户来说，包装器只是一个类型安全的容器，与其他容器一样。
顺便说一句 - 在实现模板包装器时，请注意相关名称问题。