问题标签 [spdlog]

我在我的库中使用 spdlog 和 gtest。我需要将一些日志（不是 gtest 日志）从测试执行保存到文件中。这是创建记录器的代码：

它在我的库的示例程序中运行良好。当我运行测试时，debug_logger将所有内容保存在文件中，但logger什么也不保存。当我删除

debug_logger也不工作。所以我认为这是记录器的问题但是当我添加

它仍然无法正常工作。

这是测试的主要内容：

设置和测试用例之一：

debug_loggerwith level也debug保存info日志，但不保存。loggerdebug

您是否知道我的代码中的测试和记录器初始化有什么问题？我应该在我的库中使用两个记录器还是一个带有两个文件？

我想为范围声明标识符，这些标识符将用于自动填充最内层范围内的任何日志记录语句的字段。它们通常但不总是（例如 lambdas，用 引入的块{}）匹配封闭块的“名称”。

用法看起来像这样：

结果是这样的：

我们可以通过定义宏来获得最内部的范围，LOG_CONTEXT以便它声明一个结构。然后在LOG_*宏中我们调用它的静态方法来检索名称。我们将整个事情传递给一个可调用对象，例如：

我被困的地方是构建上下文堆栈以在定义最里面的__log_context__. 我们可以使用不同命名的结构和宏约定来添加 1 或 2 个级别（例如LOG_MODULE可以定义 a __log_module__），但我想要一个更通用的解决方案。以下是我能想到的让事情变得更容易的限制：

1. 范围嵌套级别可能有合理的界限，但用户不应该提供当前级别/代码可以移动到不同的范围而不被更改。也许 16 个级别就足够了（这给了我们 orgname::app::module::subsystem::subsubsystem::detail::impl::detail::util 一些空间......）
2. 一个范围内（在单个翻译单元中）的下一级范围的数量可能是有界的，但应该比 1 的值大得多。也许 256 是合理的，但我相信有人会有一个反例。
3. 理想情况下，相同的宏可用于任何上下文。

我考虑了以下方法：

1. using __parent_context__ = __log_context__; struct __log_context__ ...

   希望能够__parent_context__获取外部上下文，但是我收到编译器错误，表明类型名称必须明确地引用同一范围内的单个类型。此限制仅在用于类的主体时适用，否则这将适用于函数和命名空间。

2. 跟踪适用于范围的结构，例如boost::mpl::vector

   本教程中的示例使我相信我会遇到与 1 中相同的问题，因为在被推送到之后的向量需要被赋予一个不同的名称，这需要在嵌套范围内专门引用。

3. 使用预处理器计数器生成适用的外部范围的名称。

   这将在我上面的简单用法示例中起作用，但在相应类之外的命名空间或方法定义中存在不连续声明时会失败。

如何在嵌套范围内访问此信息？

我需要在一些代码之前关闭 spdlog 级别，然后将其返回到之前的值。

如何在关闭之前获得当前级别？

我正在使用spdlog库进行 C++ 日志记录。我有一个同时具有sincsstdout和rotating_file_sink_mtsincs 的记录器：

我想为不同的 sincs 提供不同的日志格式。例如，标准输出的非常简单的格式（默认）和基于文件的 sinc 的 json 格式（由日志索引服务解析）。这在 spdlog 中可能吗？

我有一个 C++ 桌面应用程序，可以使用“spdlog”库（https://github.com/gabime/spdlog）记录消息。现在，我想从动态加载的 DLL 中使用相同的记录器。但是，当我尝试使用 DLL 中的 spdlog 时，我遇到了崩溃。

如何设置动态加载的 DLL 以使用与主应用程序相同的记录器？

我正在使用 spdlog 登录 Visual Studio 项目。我在 Qt creator 中使用了相同的项目，然后 spdlog 日志记录不输出任何内容。但 std::cout 仍然有效并打印到 Qt 创建者的应用程序输出窗口。

我正在尝试在你好世界中使用 spdlog 库。

由于它是“仅标题”库，我只是将它复制到我的项目的根目录并期望一切正常工作。

但是当我建立gcc hello.cpp

我明白了：
spdlog/spdlog.h:10:10: fatal error: spdlog/common.h: No such file or directory #include "spdlog/common.h"
问题是 spdlog 库中的任何地方都引用了 spdlog 文件夹下的文件。在上面的示例错误中，spdlog.h 包含位于同一文件夹中的 common.h。但它是这样包含的：
#include "spdlog/common.h" 为什么“spdlog”会出现在所有标题的所有包含中？
为了使用 spdlog，我应该怎么做？编辑它的包含？

我正在尝试使用 spdlog 作为日志库，但我不想使用我的包管理器 (apt) 来安装它。我已将 include 下的 spdlog 目录复制到项目目录的根目录，但是当我尝试编译时出现包含错误，因为#includespdlog 标头中的指令都是绝对的（相对于项目根目录），而不是相对的，gcc 不能找到文件。

如果没有将 spdlog 库中的所有包含更改为相对，我如何在我的项目中使用 spdlog？我也在使用 CMake 来编译我的项目；我的项目根目录中有一个build目录，我在其中调用cmake ..然后make编译；我需要添加到我的 CMakeLists.txt 文件中以包含 spdlog 吗？

我正在尝试将 spdlog（仅标头日志库）集成到 C++ 项目中，但我无法让 CMake 正确识别包含路径。我在 Ubuntu 18.04 上使用最新的 CLion 和 CMake 3.10.2。

我的项目结构如下所示： Project Dir |- libs | |- spdlog #this is the include directory taken straight from GitHub | |- src | |-... |- CMakeLists.txt 在CMakeLists.txt文件中我定义了包含目录：
include_directories("libs/")

现在，当我尝试写入#include <spdlog/spdlog.h>位于src/CLion 中的头文件时，会抱怨它无法找到spdlog.h，即使我已经检查过并且该文件肯定在spdlog文件夹中。在 include 语句中使用引号而不是尖括号并不能解决问题，但是使用相对于文件的路径（例如../libs/spdlog/spdlog.h）可以正常工作。更让我困惑的是，在对应头文件的源文件中，我可以包含该文件没有问题。

我无法在任何地方找到类似的问题，我正在努力理解是什么导致 CMake 或 CLion 表现得像这样。

编辑：根据 Matthieu Brucher 的建议，我尝试使用包含文件夹的完全限定路径，但它仍然不起作用。问题似乎是在标题中似乎无法识别文件夹，因为它们在源文件中工作。

EDIT2：这是CMakeLists.txt我正在使用的全部内容。它嵌套在与整个项目的顶层不同的目录CMakeLists.txt中，因为这是我在网上找到的唯一解决方案，可以在 CLion 的解决方案中获得类似于 VS 的多个项目的东西。但是，由于所有路径都是相对的，我认为这不是问题。我也知道 spdlog 是一个 C++11 库，但在不久的将来我会在其他地方需要一些 C++14 功能。

EDIT3：当我试图重新创建错误以显示以某种方式给出的完整消息时，它已经消失了，被一个与 CMake 完全无关的不同消息所取代......

昨天我已经开始spdlog在我的一个个人项目中加入日志记录。到目前为止，我在让库包含工作方面遇到了一些问题，但现在已经完全解决了。

现在一切都编译得很好，但是当我尝试创建记录器或简单地设置记录代码崩溃的模式时，发现了所有标头。更具体地说，无论我spdlog在程序中第一次从命名空间调用哪个函数都会导致崩溃。

我有一个类从spdlog（基于this repo）中抽象出一些部分，如下所示：

从堆栈跟踪来看，问题似乎在于由于某种原因在库中的某处设置了formatter类。我正在使用最新的 CLion，C++14（我知道 spdlog 是 C++11，但我需要 14 以后的功能，设置 -std=c++11 也不能解决问题）以及 Ubuntu 18.04 上截至昨天的最新版本（直接从他们的 GitHub 存储库中提取）。spdlognullspdlog

编辑：根据评论中的要求，我创建了一个小项目（单个 cpp 文件，包括我在真实项目中的操作方式，或者与从文件引用并链接到spdlog的真实项目中相同的代码和库设置main.cpp) 旨在重现该问题，这是我的发现： * 当我spdlog直接在可执行文件中使用时，问题不存在 * 如果 Logger 类被移动到共享库并从那里链接到，则存在问题

这是我收到的错误消息：

还有我正在使用的 CMakeLists.txt 文件（我将库的一个嵌套到项目中，因为到目前为止 CLion 不支持“同一解决方案中的多个项目”，例如 VS）：#CMakeLists.txt for Library cmake_minimum_required(VERSION 3.10 致命错误）