Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Matt Godbolt
    @mattgodbolt
    and I realised I didn't have it on CE
    Victor Zverovich
    @vitaut
    This is awesome, thanks @mattgodbolt !
    Matt Godbolt
    @mattgodbolt
    No problem :)
    Amos Bird
    @amosbird
    Hey, how can I print bitmap using fmt?
    Victor Zverovich
    @vitaut
    @amosbird what kind of bitmap are you referring to?
    Amos Bird
    @amosbird
    ah, i mean std::bitset<64>(long long)
    Francesco Biscani
    @bluescarni
    Hello! I noticed that fmt::format() fails with a static assertion failure if the type being formatted does not provide a streaming overload or a format_arg() overload. I was wondering if it would be possible to have (optionally?) a soft SFINAE failure instead.
    Francesco Biscani
    @bluescarni
    My use case is type-traiting/meta -programming. E.g., I would like to be able to write a type trait that detects if a type can be formatted
    Victor Zverovich
    @vitaut
    @amosbird, {fmt} doesn't provide any built-in facilities to format bitset, but you can easily write your own formatter: https://godbolt.org/g/bj6FBU
    @bluescarni, the master branch doesn't static_assert any more: https://godbolt.org/g/ksNh2m
    Francesco Biscani
    @bluescarni
    @vitaut awesome, thank!
    kamalgs
    @kamalgs
    Hi, Is it possible to make a copy of fmt::ArgList for later use. I am trying to move the actually formatting to a background thread. The idea is to push the format string and the ArgList to a queue which will then be poped out by the background thread. From a brief look it seems that the ArgList holds pointers to objects on the stack and it is not valid once the function execution is completed. Is there support for making a deep copy of the ArgList, if not some pointers on how to go about it would be appreciated. Thank You.
    Victor Zverovich
    @vitaut
    @kamalgs , generally you can't use ArgList for this, but please see https://github.com/fmtlib/fmt/issues/652#issuecomment-366551952 for a solution.
    Francesco Biscani
    @bluescarni
    I hacked together some type traiting for detecting the availability of fmt::format(), if anyone's interested:
    https://godbolt.org/g/dCJgEA
    couldn't check directly the presence of the function so I had to go through some roundabout way, but it seems to work
    Victor Zverovich
    @vitaut
    @bluescarni cool, thanks for sharing!
    Daniel Lim Wee Soong
    @daniellimws
    hi may I check if fmt::ArgList is still working in the latest version of fmtlib?
    i keep getting errors of it not existing
    Victor Zverovich
    @vitaut
    @daniellimws fmt::ArgList was renamed to fmt::format_args in the development (master) branch which now tracks the paper http://fmtlib.net/Text%20Formatting.html
    Daniel Lim Wee Soong
    @daniellimws
    @vitaut thanks a lot!
    Daniel Lim Wee Soong
    @daniellimws
    @vitaut did anything change with respect to FMT_VARIADIC? because now that code also stopped working, telling me that FmtLogMessage is not a type, where FmtLogMessage was declared as void FmtLogMessage(Class log_class, Level log_level, const char* filename, unsigned int line_num, const char* function, const char* format, fmt::format_args args);
    Victor Zverovich
    @vitaut
    Yes, FMT_VARIADIC macro which was used to emulate variadic templates is gone in master and variadic template support is required now. You can still use {fmt} 4.1 if you use a compiler that doesn't implement variadics.
    Daniel Lim Wee Soong
    @daniellimws
    ok thanks :D
    Daniel Lim Wee Soong
    @daniellimws

    hi, may I know if there is an elegant way to define variadics in cpp files instead of headers, without using fmt_variadic?

    as to why not just use 4.1, it turns out that it doesn't compile on openbsd
    more information here citra-emu/citra@fd79b70

    Victor Zverovich
    @vitaut
    Variadic templates should normally defined in header files. You could try explicitly instantiate them in a .cpp file, but this will have to be done for every combination of argument types which is problematic.
    But you can use type erasure and only define small inline variadic wrappers in the header file while placing the definition of functions taking format_args and do the actual work in the .cpp files.
    Here's an example: https://godbolt.org/g/UkZBwg
    Daniel Lim Wee Soong
    @daniellimws
    thanks a lot!
    Patrik Weiskircher
    @pweisk_twitter
    Hello! We're using fmt pretty extensively in one of our projects. During "Let's Polish This Thing!" week I ran Bloaty McBloatface on our binary and it shows that fmt::BasicWriter<>::write_int<>() is taking up 2.11Mi. This seems a little excessive to me and I'm wondering if you ever heard anything about that before?
    This message was deleted
      13.8%  2.02Mi fmt::BasicWriter<>::write_int<>()                                                 2.11Mi   5.1%
          20.1%   416Ki void fmt::BasicWriter<char>::write_int<long long, fmt::FormatSpec>(long long, fm   430Ki  19.9%
          19.8%   409Ki void fmt::BasicWriter<char>::write_int<unsigned long long, fmt::FormatSpec>(unsi   424Ki  19.6%
          19.8%   409Ki void fmt::BasicWriter<char>::write_int<unsigned long, fmt::FormatSpec>(unsigned    424Ki  19.6%
          18.6%   385Ki void fmt::BasicWriter<char>::write_int<int, fmt::FormatSpec>(int, fmt::FormatSpe   400Ki  18.5%
          18.3%   379Ki void fmt::BasicWriter<char>::write_int<unsigned int, fmt::FormatSpec>(unsigned i   393Ki  18.2%
           3.5%  71.6Ki void fmt::BasicWriter<char>::write_int<bool, fmt::FormatSpec>(bool, fmt::FormatS  86.1Ki   4.0%
    Patrik Weiskircher
    @pweisk_twitter
    Oh wait. I should try updating. Apparently we're still on 4.1
    Patrik Weiskircher
    @pweisk_twitter
    Oh boy. Updating to 5.1 and our (unstripped) binary went from 41.1mb to 58.5mb
    Stripped it's still 9mb bigger
    Patrik Weiskircher
    @pweisk_twitter
    Ooooh. I think I'm after FMT_USE_EXTERN_TEMPLATES
    Victor Zverovich
    @vitaut
    Looks excessive =). Could you give an example that reproduces the issue?
    Patrik Weiskircher
    @pweisk_twitter
    @vitaut I'm still trying to completely understand what is even happening. So far I figured out that each of these methods is 117(!) times in the binary. I always thought the linker should eliminate the duplicates but for some reason it doesn't seem to be doing that here. To be fair, I don't know enough about these low level workings yet ;)
    Patrik Weiskircher
    @pweisk_twitter
    Alright, by removing a stray fmt::header-only thing and adding a ton more extern template into format.h/format.cc I can bring the binary size down.
    Victor Zverovich
    @vitaut
    Which compiler and OS do you use?
    Patrik Weiskircher
    @pweisk_twitter
    @vitaut We're using clang-6.0 and I've seen these issues when compiling for iOS, Linux and Android. But I'm pretty confident this actually has nothing to do with fmt, but our setup
    Victor Zverovich
    @vitaut
    I see. Well, let me know if there is anything on fmt's side that can be changed to prevent this.
    Gerard Choinka
    @gchoinka
    Hi
    https://wandbox.org/permlink/3ccbQfOtOKpNpLE7 I've prepared a suggestion for named arguments, I'm not sure if I should develop it up to a real pull request
    Gerard Choinka
    @gchoinka
    By the way very nice library, thanks a lot
    Victor Zverovich
    @vitaut
    Hi Gerard!
    Thanks for the suggestion. So the difference from existing named arguments API is that you can pass several arguments at once?
    Gerard Choinka
    @gchoinka
    not exactly, it just removes you from the need to use fmt::arg{<name>, <value>} or <name>_a=<value>, but if i think about it would be also able to have named arguments without fmt::arg or _a just by expecting an even number of arguments and the even arguments are the names for the next following odd argument
    Victor Zverovich
    @vitaut
    Interesting. My main concern is that the argument and values are mixed in the same list which affects readibility. Maybe something like args{{"name", "World"}, {"number", 42"}} would be better?
    It's kind of like constructing a dictionary of named arguments.
    Gerard Choinka
    @gchoinka
    I think you concern is right, formatting tools would not care about even names and odd values