tt4g
tt4g
I don't understand the question. What were you expecting? And the term “file descriptors” is ambiguous. Are you referring to the log file descriptor?
At least sinks with the `_st` suffix are not thread-safe. When using the async logger, you should use thread-safe sinks with the `_mt` suffix. See also Wiki: * https://github.com/gabime/spdlog/wiki/Thread-Safety *...
Thank you for the report. It's surprising that no one noticed this issue. As a unit test, I believe it should not be affected by `tweakme.h`. Could you please verify...
> Missing out on `constexpr`. At least at compile time, `std::basic_format_string` appears to be a compile-time constant in order to parse the format string: https://en.cppreference.com/w/cpp/utility/format/basic_format_string.html However, since format arguments support...
Yes. `std::basic_format_string` is always evaluated as a compile-time constant. And we have a constraint that we cannot construct format strings at runtime without explicitly using [`std::runtime_format()`](https://en.cppreference.com/w/cpp/utility/format/runtime_format.html) (supported since C++26). But...
I can't help because I don't know the source code that is causing the compilation error. Please provide the code that is causing the error and the complete error message.
Do you want coverage to be 100%? Some say that should not be the goal, but why would you want to do that?
I think PR is acceptable if it does not change the behavior of spdlog. Note that a PR that changes behavior for the motive of “for coverage” is unlikely to...
FYI. due to the nature of the C++ language, coverage may not be high: [c\+\+ \- constexpr constructor won't show coverage data \- Stack Overflow](https://stackoverflow.com/questions/47820014/constexpr-constructor-wont-show-coverage-data)