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;
  /* ... */
};

They serve basically the same purpose, why do they have differences, specifically no column in stacktrace_entry, or not even share the same class?

CodePudding user response：

They serve basically the same purpose,

They do not serve the same purpose: if anything the entirety of source_location offers specific compile-time information which happens to be a small subset of the wider use case of stacktrace_entry (particularly it's source_file query member function).

P0881R7 (A Proposal to add stacktrace library) introduces the stacktrace library with larger scope or providing details about a call sequence during run-time:

In the current working draft [N4741] there is no way to get, store and decode the current call sequence. Such call sequences are useful for debugging and post mortem debugging. [...]

This paper proposes classes that could simplify debugging and may change the assertion message into the following: [...]

Note on performance: during Boost.Stacktrace development phase many users requested a fast way to store stacktrace, without decoding the function names. This functionality is preserved in the paper. All the stack_frame functions and constructors are lazy and won't decode the pointer information if there was no explicit request from class user.

P1208R6 (Adopt source_location for C 20) introduces source_location which has more narrow scope, particularly offering certain information about the source code as compile-time information.

The review of P0881 offered some feedback from SG16 on the overlap between the libraries:

SG16 discussed a number of options including the possibility of source_file() returning std::filesystem::path. SG16 converged on the following recommendation: "Align behavior with source_location; remove wording regarding conversion; string contents are implementation defined. ". No objection to unanimous consent.

However focusing on the source_file() query function of the stacktrace_entry class as something to align with the entirety of source_location. Again placing emphasis on the fact that stacktrace_entry serves a much wider purpose that the narrow compile-time information of source_location (which, as above, can be viewed as a subset of the stacktrace_entry information).