by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Victor Zverovich
    @vitaut
    Tests do require exceptions I believe.
    Andrew
    @randrewy
    Good, thanks, I'll try it and make a PR if the result will be functional :)
    Matthias Moulin
    @matt77hias
    Hey, the latest release is from Sep 21. I updated my {fmt}/master from September 22 (should be pretty similar to latest release) to November 16, but my code base no longer compiles. Are there any major possibly breaking design decisions in between?
    An apparent change is the replacement of the FMT_MAKE_VALUE macro with the make_value.
    Victor Zverovich
    @vitaut
    What code doesn't compile and what is the error message?
    Matthias Moulin
    @matt77hias
    Basically, the static_assert's condition of make_value
    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?
    Matthias Moulin
    @matt77hias
    Or if you advise to not use the master branch, I'll just revert to the latest release?
    Matthias Moulin
    @matt77hias
    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
    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
    That said, here's the PR that changed likely affected the behavior: fmtlib/fmt#907
    Matthias Moulin
    @matt77hias
    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
    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?
    Victor Zverovich
    @vitaut
    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.
    Matthias Moulin
    @matt77hias
    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).
    Victor Zverovich
    @vitaut
    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.
    Matthias Moulin
    @matt77hias
    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.
    Victor Zverovich
    @vitaut
    Sure, that's why I'm open to a PR to make specialization of formatter for non-native string types possible although I'd recommend the non-common approach.
    Matthias Moulin
    @matt77hias
    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).
    Germán Méndez Bravo
    @Kronuz
    I'm using fmt 5.2.1, but simply including it and doing some simple print takes vary long to compile... what makes the compilation so slow?
    Victor Zverovich
    @vitaut
    Make sure to use the core API that is optimized for compile time: http://fmtlib.net/latest/api.html#core-api
    Mateusz Janek
    @stryku
    Hello, which clang-format version does fmt use?
    Victor Zverovich
    @vitaut
    {fmt} doesn't use clang-format, but the coding conventions are described in https://github.com/fmtlib/fmt/blob/master/CONTRIBUTING.rst
    Mateusz Janek
    @stryku
    Yes, I saw that. Well, that explains a lot, thanks (:
    devhandle
    @devhandle
    Hi -I've just started using fmt in spdlog. Is there are a way to set a width of a string which will truncate the contents if it's > width. I'm using "{:<30}" but the string is not being truncated. thanks
    Mateusz Janek
    @stryku

    Hi, have you tried with precision?

    For non-number types the field indicates the maximum field size - in other words, how many characters will be used from the field content.

    Try {:.30}

    devhandle
    @devhandle
    Thanks @stryku, that works great.
    Mateusz Janek
    @stryku
    Np, glad to hear
    Dirk Van Haerenborgh
    @vhdirk
    Hi guys
    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}
    Victor Zverovich
    @vitaut
    No, but it's possible to do by removing a prefix from a string view, something like:
    std::string_view s = ...
    if (s.size() > 30) s.remove_prefix(s.size() - 30);
    and formatting the resulting string view if needed.
    Dirk Van Haerenborgh
    @vhdirk
    @vitaut thanks, but that would mean that I'd have to do that in code, rather than in the formatter string
    Victor Zverovich
    @vitaut
    Yes. alternatively you could write a custom formatter, but that's probably an overkill.
    Patrick Bos
    @egpbos
    hey, i'm working on a multi-process code from which i want to print diagnostic stuff to stdout, and it's quite a lot, so output from different processes is getting mixed up
    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
    Patrick Bos
    @egpbos
    the simplest thing i could think of is to just have an adjustable size buffer which i could then tune to only output stuff from each process after some specified criterium to make sure that no output gets scattered across buffer flushes as is happening now
    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
    Victor Zverovich
    @vitaut
    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.
    Patrick Bos
    @egpbos
    ok, thx for your response!
    genuine_
    @blaquee
    you might need to implement some internal lock mechanism
    but it would probably throttle output
    Patrick Bos
    @egpbos
    yeah, that's not good