These are chat archives for fmtlib/fmt

17th
Nov 2018
Matthias Moulin
@matt77hias
Nov 17 2018 14:13
I created a separate Godbolt example (https://godbolt.org/z/dfxuOL) that does not compile with the current trunk, but compiles with the latest release. Without digging deeper into my code base^^, I am quite certain I have the same problem.
And to support minimal reading: https://godbolt.org/z/CEit-x
Victor Zverovich
@vitaut
Nov 17 2018 16:49
I wouldn't recommend such implicit mixing of multi-byte and wide strings. If you want the conversion it's better to introduce a new type that does it and specialize formatter for this type. Something along the lines of format("{}", utf8(L"...")).
Victor Zverovich
@vitaut
Nov 17 2018 16:55
That said, here's the PR that changed likely affected the behavior: fmtlib/fmt#907
Matthias Moulin
@matt77hias
Nov 17 2018 17:26
Unfortunately, this is the reality on Windows :( (if std::filesystem::path would use UTF8 instead of UTF16, I wouldn't need the multi-byte strings at all).
And all other Windows APIs requiring wchar_t* filenames as well.
Matthias Moulin
@matt77hias
Nov 17 2018 17:46
No idea what that PR is talking about. Why can't the formatter not handle the type directly (the formatters that I provided, seem to handle all cases)? Furthermore, between char and wchar_t there are basically four combinations of format and format arguments, why does only one of them not work anymore as intended?