Why is C++23 stacktrace_entry different from 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;
  /* ... */
};

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

Carbonate

source_location is compile-time information of the current location in the source, while stacktrace_entry is run-time information of the current call-stack. – Lashanda

They serve completely different purposes. – Fundy

Answer 1

The answers from the proposal author.

Regarding returning std::string:

As it is stated in P0881R7: "Unfortunately this is a necessarity on some platforms, where getting source line requires allocating or where source file name returned into a storage provided by user."

Regarding column:

Most popular solutions for non-Windows platforms do not provide a source_column(). At the moment std::stacktrace is a minimal subset of abilities of all platforms, so the column is missing. This could be changed later, the addition seems quite simple for C++ standardization.

Carbonate

Answer 2

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).

Thirza

This clarifies about deliberate distinct classes, but still why doesn't the wider stacktrace_entry have the column? – Carbonate

@AlexGuteniev I anything it doesn't belong in stacktrace_entry (it's a very minor detail) but rather in string source_file() const;. As quoted above " string contents are implementation defined." - it's up to the implementor how far to align the resulting string with the entirety of source_location. – Thirza