C++ Logo


Advanced search

Re: Fwd: about reusing source_location type

From: Jason McKesson <jmckesson_at_[hidden]>
Date: Wed, 4 Aug 2021 15:21:30 -0400
On Wed, Aug 4, 2021 at 2:17 PM Edward Catmur via Std-Discussion
<std-discussion_at_[hidden]> wrote:
> On Wed, 4 Aug 2021 at 16:40, Jason McKesson via Std-Discussion <std-discussion_at_[hidden]> wrote:
>> On Wed, Aug 4, 2021 at 10:28 AM Jordi Vilar via Std-Discussion
>> > Is there any deep reason for not having a constructor allowing
>> > initializing all four fields?
>> A `source_location` should either be a valid location in the source
>> (aka: the return value of some call to `current()`), or it should be
>> nonsense data.
> Why? It'd be useful to be able to refer to locations referred to in a std::stacktrace_entry,

Then whatever `stacktrace_entry` is, it should produce one. That is,
when you retrieve such an object, it should have a `source_location`
in it (or be able to construct one) that represents the location in
the source for that entry.

The user (ie: not the standard library) should not be able to
construct such a location.

> or in a program other than the current program being executed - when writing e.g. a compiler, an IDE, or some other development tool.

Why does it have to be a `std::source_location`? That type wasn't
created just to hold a couple of `char const*`s. It's supposed to mean

> I realize that this isn't currently allowed by the API, but that doesn't in itself make it a bad idea.
>> It should *never* store values manufactured by user
>> code.
> The #line directive allows the user to store arbitrary values for file_name() and line() at compile time.

That's preprocessor magic; we're talking about the actual C++ language.

Received on 2021-08-04 14:21:42