std::source_location doesn't work if you need strings to be types

At least this part is not entirely correct, the following compiles in C++20:

  consteval std::string_view filename(const std::source_location &loc = std::source_location::current()) {
    return loc.file_name();
  }

[0] https://godbolt.org/z/K6ejTr9cn

We are seeing binary sizes increase by 30-50% just from enabling source location, even if we don’t want function_name. Sadly this means we need to turn it back off again and go back to __FILE__ and __LINE__.

It can also be used in an NSDMI, in which case it ends up being instantiated whenever the NSDMI is used, i.e. at every aggregate initialization site.

https://godbolt.org/z/v5rhjqdbY

Of course, that doesn't really allow you to do anything that you couldn't already do in the with a constexpr function (see below). In particular, such a struct can be used as a non-type template parameter, but a `template<NSDMI sloc = NSDMI{}> void foo();` will merely report the line where the template is defined, not where `foo` is called.

    // Results in a compile-time constant, so can be used everywhere where __LINE__ could be used.
    constexpr int line(std::source_location loc = std::source_location::current()) { 
       return loc.line();
    }

No, only the code that references __FILE__ needs to be a macro. Usually what i see is a logging function that takes line and file as arguments, and then a macro that calls the function with __FILE__ and __LINE__.

struct fstr { constexpr fstr(const char* s) { for (length = 0; s[length] ; length++) data[length] = s[length]; }

    char data[256] = {0};
    size_t length = 0;

template <fstr sz> struct log { log() { std::cout << std::string_view{ sz.data, sz.length } << std::endl; } };

int main() { log<fstr(std::source_location::current().file_name())> _; }

There are a lot of language features that aren’t suitable to specific contexts like embedded or realtime.

It’d be interesting to see if this concern was raised during discussion of source_location and whether a rationale was established, but I wouldn’t go so far as to say it’s broken when it just happens not to be suitable to a specific, narrow implementation context.

But there is a big catch: the range must be returned from a constexpr function. So to get the correct source_location object you always need to spell out the entire `to_static_array<100>([] { return current_file_name(); }` expression where you need it.

So while this does work for source_location::file_name() it doesn't for source_location::function_name() as that will always result in the name of the lambda.

So it's only a partial solution. And has terrible ergonomics for this particular use case. so I don't think we have completely eliminated the need for macros just yet.

But other than that it's a great tool if you want to do some constexpr computations with std::vector or std::string and then turn the result into a constant-sized compile-time array, optionally baking it into the binary.

  #include <stdio.h>
  
  #include <array>
  #include <source_location>
  #include <string_view>
  
  template<size_t N> constexpr auto GetFilename(char const name[]) {
    std::array<char, N + 1> a = {};
    std::char_traits<char>::copy(&a[0], name, N);
    return a;
  }
  
  template<auto Value = GetFilename<
             std::char_traits<char>::length(std::source_location::current().file_name())
           >(std::source_location::current().file_name())>
  using SL = std::integral_constant<decltype(Value), Value>;
  
  int main() {
      printf("%s\n", &SL<>::value[0]);
  }

A good, straightforward solution, using existing tech, is hidden in some leaf comment, or not actually there explicitly. I would guess >>50% of the posters don't know that this is doable. Let me type it out:

    void actual_logging_function(std::string_view filename, int line, std::string_view msg)
    {
        printf("In %.*s.%d: %.*s\n", filename.length(), filename.data(), line, msg.length(), msg.data());
    }

    #define logging_function(msg) actual_logging_function(std::string_view(__FILE__), __LINE__, (msg))

I get it. Macros are terrible. But can we stop coming up with "solutions" that are even more terrible, just on other axes?

And really, the initial "problem" was just that the string length wasn't a compile-time constant. I would venture out and claim that this isn't an actual problem, unless "logging" is confused with "high-performance string formatting". If an application is logging at a rate where a simple "%s" becomes an issue, isn't there something else that is broken? And for context - typically a logging call also has to do other formatting that can't be moved to compile time, such as formatting integers.

"foo()::<lambda()#1>"

I remember writing some constexpr expressions to strip the lambda portion (which had a guid). Is there now an easier way?

This post reads to me like complaining that your hammer ruined your screw.

Because if so, you could just ... not dereference the pointer, and do object-file magic to make the section not actually mapped.

  string_constant<'H', 'e', 'l', 'l', 'o'>