4 ms·
What do you mean? They do. They want to replace the name of the file with a number at compile time so that the logs are tiny. The way they do that now is that
by vlovich123 3y ago
What do you mean? They do. They want to replace the name of the file with a number at compile time so that the logs are tiny.
The way they do that now is that they pass __FILE__ to a char parameter pack expansion to generate a unique type that erases to nothing but a number at compile time and extract the unique id of that type using nm but that doesn’t work with source_location because it has char* as the type.
I wonder if there’s some kind of workaround where you wrap source_location so that it outputs the hash of the file name using a know consteval hashing function. Then you have your unique type (just assign the hash value to your type) at the cost of some extra overhead of needing to hash every filename in your build.
- nemetroid 3y agoThat's a prose description, not code.
- nottorp 3y agoI thought one of the basic skills of programming is to turn a prose description into code...
- nemetroid 3y agoI don’t think I’ve claimed otherwise.
- Dylan16807 3y agoDoing that takes a lot of time. It would help the article to spell it out somewhat better. Or at least copy a couple slides from the video.
- tom_ 3y agoAnd one of the basic problems of programming is that the resulting code is almost certainly wrong. Which is why it's always safest to look at the specific code in question, rather than a description of what it's supposed to do.
- ynik 3y agoBut it's quite unclear what they are currently doing. Literally translating what you are describing: template<char... FILE> struct magic { }; magic<__FILE__> m; This does not compile with gcc, and std::source_location fails to work for exactly the same reason. I don't see any additional problems with std::source_location that don't equally apply to __FILE__.