4 ms·

If the blog post author showed us the code they want to write (but doesn't work), it might be easier to understand what they mean.

Joker_vD 3y ago
I imagine they want something like this [0] but only with even less string pointers, using e.g. hashes or globally assigned numbers instead. [0] https://www.embeddedrelated.com/showarticle/518.php https://www.embeddedrelated.com/showarticle/518.php
ReleaseCandidat 3y ago
It's this problem: https://stackoverflow.com/questions/52977593/stdexperimentalsource-location-at-compile-time/52977844#52977844 https://stackoverflow.com/questions/52977593/stdexperimental...
- deleted 3y ago
  [deleted]
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 ago
  That's a prose description, not code.
  - nottorp 3y ago
    I thought one of the basic skills of programming is to turn a prose description into code...
    - nemetroid 3y ago
      I don’t think I’ve claimed otherwise.
    - Dylan16807 3y ago
      Doing 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 ago
      And 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 ago
  But 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__.
senkora 3y ago
They did link an hour long conference talk (which I haven't watched), that I assume explains in more detail the kind of logging system that they're working with: https://www.youtube.com/watch?v=Dt0vx-7e_B0 https://www.youtube.com/watch?v=Dt0vx-7e_B0 I think that basically they want a class template magic_functor that can be invoked as below magic_functor<std::source_location::file_name()>::type And then they could get a compile-time number corresponding to the file_name by doing: using T = magic_functor<std::source_location::file_name()>::type; int x = my_logging_lib_string_to_number<T>(); But unfortunately it simply doesn't work, because magic_functor is unwritable, because a `const char *` doesn't remember its size like a `const char[]` does.
- ynik 3y ago
  If the `const char*` is a compile-time value, you can get its size via `std::char_traits<char>::length()`. Here I could get `magic_functor<std::source_location::file_name()>::type` to work on MSVC: https://godbolt.org/z/Ph8dd78fa https://godbolt.org/z/Ph8dd78fa gcc doesn't accept this code, but that seems more like an implementation problem than a specification problem?
  - gpderetta 3y ago
    There are a lot of restrictions on what a pointer-type template parameter can point to. In particular it needs to have linkage (which for example string literals do not have). Whether the results of constexpr functions must, can or can't have linkage is beyond my paygrade, but I suspect this is an MSVC extension. edit: linkage appears to propagate through constexpr. So it depends on how ultimately the original string is generated. I don't know what guarantee the standard gives (cppreference doesn't mention anything and I can't be bothered to look at the standard).
- jeffreygoesto 3y ago
  I liked this better, it uses some macros but it's easily readable and compresses the logs nicely. https://youtu.be/FyJI4Z6jD4w https://youtu.be/FyJI4Z6jD4w

Joker_vD 3y ago

I imagine they want something like this [0] but only with even less string pointers, using e.g. hashes or globally assigned numbers instead. [0] https://www.embeddedrelated.com/showarticle/518.php https://www.embeddedrelated.com/showarticle/518.php

ReleaseCandidat 3y ago

It's this problem: https://stackoverflow.com/questions/52977593/stdexperimentalsource-location-at-compile-time/52977844#52977844 https://stackoverflow.com/questions/52977593/stdexperimental...

deleted 3y ago
[deleted]

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 ago
That's a prose description, not code.
- nottorp 3y ago
  I thought one of the basic skills of programming is to turn a prose description into code...
  - nemetroid 3y ago
    I don’t think I’ve claimed otherwise.
  - Dylan16807 3y ago
    Doing 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 ago
    And 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 ago
But 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__.

senkora 3y ago

They did link an hour long conference talk (which I haven't watched), that I assume explains in more detail the kind of logging system that they're working with: https://www.youtube.com/watch?v=Dt0vx-7e_B0 https://www.youtube.com/watch?v=Dt0vx-7e_B0 I think that basically they want a class template magic_functor that can be invoked as below magic_functor<std::source_location::file_name()>::type And then they could get a compile-time number corresponding to the file_name by doing: using T = magic_functor<std::source_location::file_name()>::type; int x = my_logging_lib_string_to_number<T>(); But unfortunately it simply doesn't work, because magic_functor is unwritable, because a `const char *` doesn't remember its size like a `const char[]` does.

ynik 3y ago
If the `const char*` is a compile-time value, you can get its size via `std::char_traits<char>::length()`. Here I could get `magic_functor<std::source_location::file_name()>::type` to work on MSVC: https://godbolt.org/z/Ph8dd78fa https://godbolt.org/z/Ph8dd78fa gcc doesn't accept this code, but that seems more like an implementation problem than a specification problem?
- gpderetta 3y ago
  There are a lot of restrictions on what a pointer-type template parameter can point to. In particular it needs to have linkage (which for example string literals do not have). Whether the results of constexpr functions must, can or can't have linkage is beyond my paygrade, but I suspect this is an MSVC extension. edit: linkage appears to propagate through constexpr. So it depends on how ultimately the original string is generated. I don't know what guarantee the standard gives (cppreference doesn't mention anything and I can't be bothered to look at the standard).
jeffreygoesto 3y ago
I liked this better, it uses some macros but it's easily readable and compresses the logs nicely. https://youtu.be/FyJI4Z6jD4w https://youtu.be/FyJI4Z6jD4w