7 
class stacktrace_entry {
public:
  string description() const;
  string source_file() const;
  uint_least32_t source_line() const;
  /* ... */
};

struct source_location {
  // source location field access
  constexpr uint_least32_t line() const noexcept;
  constexpr uint_least32_t column() const noexcept;
  constexpr const char* file_name() const noexcept;
  constexpr const char* function_name() const noexcept;
  /* ... */
};

它们的目的基本相同，为什么它们有差异，特别是没有列stacktrace_entry，甚至不共享同一类？

4

2 回答 2

3

它们的用途基本相同，

它们的目的不同：如果有的话，整体source_location提供特定的编译时信息，这恰好是更广泛用例的一小部分stacktrace_entry（特别是它的source_file查询成员函数）。

P0881R7 ( A Proposal to add stacktrace library ) 介绍了具有更大范围的 stacktrace 库或提供有关运行时调用序列的详细信息：

在当前的工作草案 [N4741] 中，没有办法获取、存储和解码当前的调用序列。这样的调用序列对于调试和事后调试很有用。[...]

本文提出了可以简化调试的类，并且可以将断言消息更改为以下内容：[...]

性能注意事项：在 Boost.Stacktrace 开发阶段，许多用户要求一种快速存储堆栈跟踪的方法，无需解码函数名称。此功能保留在论文中。所有 stack_frame 函数和构造函数都是惰性的，如果没有来自类用户的显式请求，则不会解码指针信息。

P1208R6 ( Adopt source_location for C++20 ) 介绍了source_location哪个范围更窄，特别是提供有关源代码的某些信息作为编译时信息。

P0881 的审查提供了 SG16 关于库之间重叠的一些反馈：

SG16 讨论了许多选项，包括source_file()返回的可能性std::filesystem::path。SG16 融合了以下建议：“将行为与 source_location 对齐；删除有关转换的措辞；字符串内容由实现定义。”。不反对一致同意。

但是将类的source_file()查询功能stacktrace_entry作为与整个source_location. 再次强调stacktrace_entry一个更广泛的目的的事实，即狭窄的编译时信息source_location（如上所述，可以被视为stacktrace_entry信息的子集）。

于 2022-02-02T08:58:02.733 回答
0

提案作者的回答。

关于退货std::string：

正如P0881R7中所述：“不幸的是，这在某些平台上是必需的，其中获取源行需要分配或源文件名返回到用户提供的存储中。”

关于专栏：

非 Windows 平台的大多数流行解决方案不提供source_column(). 目前std::stacktrace是所有平台能力的最小子集，因此缺少该列。这可以稍后更改，对于 C++ 标准化来说，添加似乎非常简单。

于 2022-02-02T20:21:20.910 回答