This shows what I perceive as a problem in the culture around C++. Tons of suggestions how to write some trivial, probably unimportant piece of code in an "optimal" way. There is a perceived problem, macros, but then 90% of those suggestions are worse.
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:
There is plain C version of this too, just replace std::string_view(__FILE__) by sth like my_string_view(__FILE__, sizeof __FILE - 1). Obviously the length also be passed directly to the logging func.
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.
void logging_function(std::string_view msg, std::source_location l = std::source_location::location()) {
// log here
}
No need for macros, it just work in almost all scenarios.
But this solution (and your __FILE__) will add a bunch of strings (representing the file names) into the read only section of the final binary so that they can be available at runtime. Apparently this is undesirable for the embedded scenario the author has in mind. So in this thread we were looking for a way to encode the source_location as a template parameter (which the author claims it can't be done) instead so that it is part of the symbol and can be stripped out.
It is a very niche need, it just turned out to be a fun game to play.
Well I have a history of missing the point for sure :-). So let me ask further, where should the string be stored if not in the read only section?
As far as I understood the post, the issue with your above code is that the std::source_location::location() isn't able to use the size (length) of the filename string at compile time (*). While with _FILE_, the size is known -- it's even in its type.
So if you want to play template or constexpr tricks, you probably can do what you have in mind using __FILE__. Just be aware that a (pointer,length) pair (like string_view) or a plain zero-terminated string pointer will have the size information available at runtime but not compile time.
So not saying that I didn't miss anything (I probably did), and not to mean any offense, but maybe you're also one of those >>50% of people that I mentioned? :D
(*) which, as you and I already agree, is probably not really an issue. It's more a "fun" game to play -- the kind of game that a lot of C++ people like to play, and then sell it as "optimal solution" or "zero-cost abstraction".
In the final binary, it would not be stored at all. The idea is that if you have can use the location as a template parameter, you can generate an unique symbol for it (say, a function) and log that address instead, stripping the actual function name from the binary. When reading the log you can map the function address to the function name and recover the source_location from that (but I'm not familiar with the actual process). The key is that the mapping need not be stored in the binary.
As shown else thread, you can easily compute the size of std::source_location::current().file_name() at compile time. The only limitation is that neither source_location nor the std::source_location::current().file_name() pointer themselves can be used directly as non-type template parameters. But there are ways around that.
And yes, you can do the same with __FILE__ and __LINE__, but you need to wrap them in a macro for usability. The question is whether there is a solution that doesn't use macros at all (I posted one elsethread).
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:
There is plain C version of this too, just replace std::string_view(__FILE__) by sth like my_string_view(__FILE__, sizeof __FILE - 1). Obviously the length also be passed directly to the logging func.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.