问题标签 [header-only]

我需要修改一个 C++ 项目以使用Cereal库。本项目的构建系统基于 CMake。由于 Cereal 是一个只有头文件的库并且也使用 CMake，我希望这是一个非常简单的任务。我尝试编辑CMakeLists.txt：

但不知何故cmake试图安装cereal在/usr/local. 我感谢任何可以为我指明正确方向的帮助。

我知道可以fmt在仅标题模式下使用格式化库：

如何在仅标头模式下使用 fmt 库？

但是 - 为什么不只是标题，句号？也就是说，在 non-header-only 模式下使用它有什么好处？

我正在尝试在 C（不是 C++）的仅标头库中实现一个全局单例变量。所以在这个论坛和其他地方搜索之后，我发现了我在这里适应 C 的 Meyer 单例的一个变体：

请注意，我正在返回一个指针，因为 C 在 C++ 中缺少 & 引用，所以我必须解决它。

好的，现在我要测试它，所以这里是一个简单的测试代码：

在 C 模式下的 MSVC 中编译和运行良好（也在 C++ 模式下，但这不是主题）。但是，在 gcc 中，它输出两个警告（警告：'foo' 是静态的，但在非静态的内联函数 'singleton' 中声明），并生成一个可执行文件，然后当我尝试运行它时会出现段错误。警告本身对我来说有点道理（事实上，我很惊讶我在 MSVC 中没有得到它）​​，但是 segfault 暗示了 gcc 永远不会将 foo 编译为静态变量的可能性，使其成为局部变量stack 然后返回该变量的过期堆栈地址。

我尝试将单例声明为extern inline，它在 MSVC 中编译并运行良好，导致 gcc 中的链接器错误（同样，我不抱怨链接器错误，这是合乎逻辑的）。我也尝试过static inline（在 MSVC 和 gcc 中都编译得很好，但可以预见的是在第三行运行时输出错误，因为 side.c 翻译单元现在有自己的单例副本。

那么，我在 gcc 中做错了什么？我在 C++ 中没有这些问题，但在这种情况下我不能使用 C++，它必须是直接的 C 解决方案。

我还可以接受任何其他形式的单例实现，这些单例实现在 gcc 和 MSVC 中的纯 C 中的纯标头库中工作。

我目前正在结束为基于网格的量子计算开发仅包含 C++ 标头的模板库，并且我正在考虑替换我几乎在一开始就编写的旧日志记录模块。

我知道让一个仅标头的库将内容打印到标准输出（和文件）听起来有点奇怪，但我大量使用模板来提高运行时二进制文件的灵活性和效率，因此选择了这个。

当前的日志记录模块使用 printf（因为我不喜欢语法 ）、std::cout宏、可变参数宏（##__VA_ARGS____FILE____LINE__

用（或类似的东西）替换它是否有意义，fmt或者我应该尝试对现有的进行现代化改造（即用模板替换可变参数宏，自定义构建的 compile-timestring_view等）？

我希望图书馆“立即”工作，也就是说，我想：

a) 尽可能多地消除依赖

b)find_package(fmt)在 CMake 中静默尝试或 FetchContent - （顺便说一句。这种行为是否有通用的 CMake“模板”？类似于“find_or_fetch”？）

c) 将基本部分fmt作为 git 子模块放在我的项目中，并包含一个小头文件。

除此之外，我还计划使用 HDF5 库（有或没有 C++ 包装器）。再次在这里，我不确定如何最好地处理它以使集成尽可能无缝，我也没有决定应该使用哪个包装器。“find_or_fetch”范式是否适合仅标头库？

我正在使用VulkanMemoryAllocation，这是一个仅限标题的库。我想使用 cmake 将它编译成一个静态库，但我最终得到一个空的 - 8 字节大小的 - 库文件，并且在链接时有很多未定义的符号。

这是相关部分CMakeList.txt

编辑：我想做与此等效的操作：

但使用 CMake

如果想尽可能避免处理，在 C++ 中实现可打印类的正确方法是什么iostream？

这个问题来自iostream,iosfwd与模板之间的交互。

1. 传统方法

据我所知，传统方法是：

我的类.hpp

然而，尽管某些类可以打印，例如用于调试，但并非所有用户都会对打印任何内容感兴趣。这些用户将（在编译时）为永远不会使用的东西付出代价。也就是包含和编译iostream.

（有，iosfwd但它对仅标题没有用。）

2. 模板operator<<

这个我不必包含iostream在头文件中。它还存在operator<<可能返回非标准对象的问题，例如std::ofstream（而不是 base std::ostream）。

对打印感兴趣的用户必须包括iostream自己（并且在某种程度上知道这一点。）

缺点是Ostream可以搭配其他东西。可以将其与iosfwd约束Ostream（例如enable_if<is_base<std::ostream, Ostream>::value>）结合使用。不确定它是否有效。

3.单独MyClass/io.hpp的打印头

添加单独的文件

我的班级/io.hpp

在这种情况下，用户必须包含MyClass/io.hpp才能打印MyClass（并且知道这一点）。

此外，打印私有成员可能需要友谊，为此它需要<iosfwd>在 MyClass.h 中。

boost/units/io.hpp我在图书馆见过这个设计。

4.结合2和3

去完整的模板

我的班级/io.hpp

std::iostream在使用模板和仅标头并iostream尽可能避免编译时，推荐的交互方式是什么？

总之，似乎使用单独的文件可以避免包含<iostream>. 模板和不需要友谊也可以避免iosfwd。受限制的模板或需要友谊的可能仍然需要iosfwd。

我正在尝试通过将所有标头放在单独的 cmake 标头项目中来重组我的 CMAKE 项目，并使用 target_link_libraries 将其添加到我的源 cmake 项目中。

在 cpp 源文件中包含标头时是否可以保留文件夹路径。

接口库中的头文件还应该能够使用头文件夹名称访问来自不同目录（在同一 cmake 接口项目中）的其他头文件。

预期的

当前工作的实现

我的界面cmake配置

我的来源 cmake 配置

也可以将所有必需的包含文件复制到构建目录中，以便在其他机器上安装时可以复制/发布这些文件。

我正在打包以下派生。

• 一个名为的 C++ 库amazing，它具有仅标头的 C++ 依赖项（此示例为nlohmann_json）。库必须是动态的（共享 ELF 文件）。该amazing库nlohmann_json在构建时需要依赖项，但在运行时不需要依赖项（nlohmann_json仅作为标头）。的用户在构建时amazing也需要nlohmann_json，否则会出现编译错误。nlohmann_json但用户在运行时不需要。
• example使用该amazing库命名的 C++ 可执行文件。
• 一个名为的 docker 容器example-docker，它只包装了example. 我希望容器包含所有需要的运行时依赖项，example但要保持最小——即，它不应该包含nlohmann_json.

我为此示例创建了一个独立的最小 git 存储库。

我当前的 Nix 设置如下所示。

Nix 设置工作（所有派生都正确构建并且容器运行良好），但容器不是最小的：nlohmann_json在容器中。

我尝试了几种方法来定义的nlohmann_json输入，amazing以便使用的派生amazing在nlohmann_json构建时具有但不强制nlohmann_json在最终容器中存在（propagatedNativeBuildInputs来自depsBuildBuildPropagatednixpkgs手册），但我无法达到预期的结果。我也尝试使用strictDeps = true;，但在这种情况下我无法构建我的派生。

是否有可能用 Nix 实现我想要的？