为什么C++23 stacktrace_entry和source_location不同？

Question

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中没有列，或者甚至没有共享同一个类？

Answer 1

提案作者的答案。

关于返回std::string

正如P0881R7中所述：“不幸的是，在某些平台上，获取源代码行需要分配，或者源文件名为重归是存储由用户提供。”

关于栏：

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

Answer 2

它们的用途基本相同，

它们的用途不同:如果说有什么不同的话，那就是整个source_location提供了特定的编译时信息，而这些信息恰好是stacktrace_entry更广泛的用例的一个小子集(特别是它的source_file查询成员函数)。

P0881R7 (添加堆栈跟踪库的建议)引入了范围更大的堆栈跟踪库，或者在运行时提供有关调用序列的详细信息：

在当前的工作草案N4741中，没有获取、存储和解码当前调用序列的方法。这样的调用序列对于调试和死后调试非常有用。..。 本文提出的类可以简化调试，并可以将断言消息更改为以下内容： 性能说明:在Boost.Stacktrace开发阶段，许多用户请求一种快速存储堆栈跟踪的方法，而不对函数名进行解码。本文保留了这一功能。所有的stack_frame函数和构造函数都是惰性的，如果没有来自类用户的显式请求，则不会解码指针信息。

P1208R6 (采用source_location for C++20)引入了范围更窄的source_location，特别是提供了关于源代码的某些信息作为编译时信息。

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

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

但是，将重点放在stacktrace_entry类的stacktrace_entry查询函数上，使其与整个source_location保持一致。再次强调的是，stacktrace_entry具有更广泛的用途，即source_location的狭义编译时信息(如上面所述，可视为stacktrace_entry信息的子集)。