问题标签 [header-only]

我想将我正在开发的库打包为仅标头库，以使客户更容易使用。（它很小，真的没有理由把它放到一个单独的翻译单元中）但是，我不能简单地将我的代码放在标题中，因为这违反了 C++ 的单一定义规则。（假设库头包含在一个客户项目的多个翻译单元中）

如何修改库以使其仅包含标题？

看来我必须在这里内联相当多的代码。我想知道将其完全留在这样的头文件中是否是不好的设计实践：

是否存在这样一种依赖模式，以至于不可能将所有内容都保存在头文件中？如果我们只强制每个标题一个类的规则怎么办？

出于这个问题的目的，让我们忽略静态的东西:)

我正在尝试为自己编写一个仅包含标题的辅助函数库。（我正在使用 boost 和 SDL，而 boost 更容易使用，所以我想为我自己的帮助库模拟它。）

我的一个班级收到错误“没有命名类型”，这让我很困惑。我知道我可以通过拼写错误或循环包含来解决这个问题，但在我的代码中找不到这些问题。SdlWindow.cpp 中的前向声明没有帮助。再次包含标题（所以我 /do/ 有一个循环包含）也无济于事（我得到“先前定义的”错误）。

主要.cpp：

SdlWindow.hpp：

和 SdlWindow.cpp：

我得到的错误是“SdlWindow'没有命名类型”，在 SdlWindow.cpp 中，我声明了两个 SdlWindow 函数。是什么原因造成的，我该如何解决？

我在 Windows Vista 上的 Eclipse 中使用 mingw32 的 gcc 进行编译。

显然模板库只需要标题，但对于非模板，你什么时候应该只做标题？

看着这个项目（http://www.savarese.com/software/libssrckdtree/），我找到了“C++ header-only template library”的定义。目前我有基本的 C++ 知识，但想知道这到底意味着什么以及为什么这个人在这个项目中使用它

我想在 .hpp 中编写代码而不分离 .h 和 .cpp

• 我做的。我仅将 .cpp 用于静态类字段定义

我不想手动编写#include ...

• 我尽可能使用前向声明。
• 我的每个 .hpp 文件都包含一次 #pragma。
• 但是，当我的项目增长到 40-50 个类时，我看到了包含图的问题。定义有一些错误。

附有我的项目模型（如 mvc 的一部分）的包含图的图像。
我使用这个应用程序生成图形（可以在没有 MSVS 的情况下工作！）。

包含图应该是什么样子？像一棵树？
如何不手动编写包含，例如在 C# 或 Java 中？

我正在开发一个相当大的 C++ 支持库，并且发现自己正在转向仅使用标头的方法。在 C++ 中，这几乎可以工作，因为您可以实现在类中定义的位置。对于模板化方法，无论如何，实现都必须在同一个文件中，所以我发现将实现与定义保持在一起要容易得多。

但是，有时必须使用“来源”。仅举一个例子，有时会出现循环依赖，并且必须在类定义之外编写实现。以下是我的处理方式：

然后使用 libfoo 的项目将在 main.cpp 中执行以下操作：

在任何其他 .cpp 中：

关键是 compile-inline 部分只编译一次（在 main.cpp 中）。

最后我的问题是：这个成语或任何其他以这种方式工作的项目是否有名称？这似乎是模板和类方法模糊了实现和定义的自然结果。并且：是否有任何理由说明这是一个坏主意，或者为什么它可能无法很好地扩展？

顺便说一句：我知道许多编码人员有充分的理由更喜欢他们的标题类似于接口而不是实现，但是恕我直言文档生成器更适合描述接口，因为我喜欢将私有成员隐藏在一起:-)

在非模板库类中拥有静态成员而不将定义成员的负担放在类用户身上的最佳方法是什么？

假设我想提供这个类：

然后该类的用户一定不要忘记在某处定义静态成员（正如已经多次回答的 那样）：

我在下面有一个答案，但它有一些缺点。有更好和/或更优雅的解决方案吗？

我试图使用 SO 找到答案。有许多问题列出了在 C++ 中构建仅包含标头的库的各种优缺点，但我一直无法找到一个以可量化的方式这样做的问题。

那么，在可量化的方面，使用传统分离的 c++ 头文件和实现文件与仅使用头文件有什么不同？

为简单起见，我假设不使用模板（因为它们只需要标题）。

为了详细说明，我列出了我从文章中看到的优点和缺点。显然，有些是不容易量化的（比如易用性），因此对于量化比较是没有用的。我将用（可量化的）标记那些我期望可量化的指标。

仅标题的优点

1. 它更容易包含，因为您不需要在构建系统中指定链接器选项。
2. 您始终使用与其余代码相同的编译器（选项）编译所有库代码，因为库的函数已内联在您的代码中。
3. 它可能会快很多。（可量化）
4. 可能给编译器/链接器更好的优化机会（解释/量化，如果可能的话）
5. 如果您仍然使用模板，则需要。

仅标头的缺点

1. 它使代码膨胀。（可量化的）（这如何影响执行时间和内存占用）
2. 更长的编译时间。（可量化）
3. 失去接口和实现的分离。
4. 有时会导致难以解决的循环依赖。
5. 防止共享库/DLL 的二进制兼容性。
6. 它可能会激怒喜欢使用 C++ 的传统方式的同事。

您可以从更大的开源项目（比较类似大小的代码库）中使用的任何示例将不胜感激。或者，如果您知道可以在仅标题版本和单独版本之间切换的项目（使用包含两者的第三个文件），那将是理想的。轶事数字也很有用，因为它们给了我一个大致的了解，我可以从中获得一些洞察力。

优点和缺点的来源：

• https://stackoverflow.com/a/6200793/278976
• https://stackoverflow.com/a/1783905/278976

提前致谢...

更新：

对于以后可能会阅读本文并有兴趣获得一些有关链接和编译的背景信息的人，我发现这些资源很有用：

• http://www.amazon.com/Computer-Systems-Programmers-Perspective-Edition/dp/0136108040第 7 章
• http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
• http://www.cyberciti.biz/tips/linux-shared-library-management.html

更新：（回应以下评论）

仅仅因为答案可能会有所不同，并不意味着测量是无用的。您必须从某个点开始测量。你的测量值越多，图片就越清晰。我在这个问题中要求的不是整个故事，而是图片的一瞥。当然，如果任何人想不道德地宣扬他们的偏见，他们都可以使用数字来歪曲一个论点。但是，如果有人对两个选项之间的差异感到好奇并发布了这些结果，我认为这些信息很有用。

没有人对这个话题感到好奇，足以衡量它吗？

我喜欢枪战项目。我们可以从删除大部分变量开始。仅在一种版本的 linux 上使用一种版本的 gcc。仅对所有基准测试使用相同的硬件。不要用多线程编译。

然后，我们可以测量：

• 可执行文件大小
• 运行
• 内存占用
• 编译时间（对于整个项目和通过更改一个文件）
• 链接时间