3 ms·

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

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

gpderetta 3y ago
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).

gpderetta 3y ago

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