Hacker News Reader

Comment by nemetroid | Hacker News Reader

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.

View on HN

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

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.

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 gcc doesn't accept this code, but that seems more like an implementation problem than a specification problem?

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

I liked this better, it uses some macros but it's easily readable and compresses the logs nicely.

https://youtu.be/FyJI4Z6jD4w

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.

That's a prose description, not code.

I thought one of the basic skills of programming is to turn a prose description into code...

I don’t think I’ve claimed otherwise.

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.

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.

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

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

It's this problem: https://stackoverflow.com/questions/52977593/stdexperimental...

Reply on news.ycombinator.com