is false. Probably, due to some wchar_t to char conversion that I need to look further into (but msvc++ is not that helpful in case of lots of template chains). So it would be helpful to know if fmt changed the API in some way, especially with regard to the formatter specializations?
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
And all other Windows APIs requiring wchar_t* filenames as well.
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?
I'm not sure why only one specialization is not working. If you are willing to debug and submit a PR I'll be happy to merge it in even though as I wrote before the recommended solution is to introduce types to do transconding explicitly. A common practice is to use UTF-8 internally and only transcode at WinAPI boundaries.
Unfortunately, std::filesystem already crosses the WinAPI boundary (character type is OS dependent). I understand that explicitizing the conversions results in a neater design, but on the other hand the formatter specializations are somewhat explicit as well. Though, they target all (common) conversions indirectly vs one particular conversion directly. In that sense, it seems imho better to introduce a separate intermediary class for explicit non-common conversions as opposed to all conversions (e.g., why is the type std::string treated different from std::vector for formatting wchar_t streams? Both are just types for which the user needs to handle the formatting).
Not sure I understand your suggestion about intermediary class for non-common conversions.
std::string is different from std::vector because the former have an well-established output format while the latter doesn't. There are some facilities to format containers in fmt/ranges.h though.
But std::string does not have a well-established output form for an UTF16 output iterator, and a std::wstring does not have a well-established output form for an UTF8 output iterator. So I do not see the differences with an arbitrary user-defined type Widget (e.g., container).
With non-common, I just refer to the same thing you proposed above (i.e. utf8): format("{}", NonCommonType(L"...")) + formatter specialization for NonCommonType.
I recommend the non-common approach as well if and only if the common case cannot be handled properly while still using the common case for the majority. The elegancy of fmt is the possibility to pass whatever arguments you want compared to printf's fixed number of types, but somehow using a wrapper for some arguments feels like going back to printf (irrespective of whether an automatic conversion could be error-prone in some non-common cases).
Make sure to use the core API that is optimized for compile time: http://fmtlib.net/latest/api.html#core-api
{fmt} doesn't use clang-format, but the coding conventions are described in https://github.com/fmtlib/fmt/blob/master/CONTRIBUTING.rst
is it possible to specify the 'precision/width' of a string field but overflow on the left part?
Using
{:.30s} will always trim the tail. adding the alignment operator just aligns the field after it's been trimmed {:>.30s}
i was naively hoping that i could control std::cout's buffer size, but apparently this is an implementation detail and in any case not part of the standard
so i'm wondering: can fmt help me here?
do you have / know of examples of using fmt in a multi-process environment?
note: not multi-threaded, so no shared memory, though I am able to communicate between processes, but would rather not, as I'm doing performance critical stuff
i guess the easiest would be to just flush after every line, but i'm afraid that would impact my performance too much
and also, i'm just looking for a good excuse to try out fmt :D
Unfortunately, I don't have any examples how to prevent mixing of output from multiple processes.
fmt::print writes the whole message atomically (using one call to the underlying system function), which prevents mixing parts of messages within the process, but I'm not sure if it helps with multiple processes.
but it would probably throttle output
i think ideally i'd have a separate process that handles output, to which other processes send their output, via a block of shared memory to prevent copies
but this is a bit outside of the scope of my project ;)
Hello, people. How is your day?
Can I get an aid with my problem? I want compile-time checks of parameters correctness (number of param mismatch etc.) with syntax like fmt::format("The answer is {:d}", "forty-two");. Is that possible? From website I only see alternative format(fmt kind of syntax that switches to compile time checks instead of throwing exceptions.
I tried DCMAKE_FMT_PEDANTIC=ONdidn't seem to help on both gcc and clang, probably it's doing not what I thought it would.
Reason to do this is to have compile-time checks for another library that uses fmt (named spdlog) while not changing anything on spdlog side...
I promise I did research myself prior to asking here, sorry for any trouble. I hope someone else had solution for this, spdlog seems to be quite popular and is mentioned in readme as a fellow library.