Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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
    Victor Zverovich
    @vitaut
    So I'm open to pull requests if this can be done in the form args{{"name", "World"}, {"number", 42"} or similar rather than just a single list.
    lyngklip
    @lyngklip
    First: good job on this library. I'm learning a lot.
    Now for a "thing" I found: I tried to combine format_to_n with a back_insert_iterator and got the compilation error "invalid use of 'std::__iterator_traits ... yadayada.. ::value_type {aka void}'.
    I think the issue is that (quote from cppreference): "Pure output-only iterator is allowed to declare its iterator_traits<X>::value_type [and others] to be void (and iterators such as std::back_insert_iterator do just that)."
    I didn't check trunk, I'm on 5.2.0.
    valuetype is used for declaring blackhole in the truncating iterator. (Underscore does things with the text, sorry)
    lyngklip
    @lyngklip
    value_type is used for declaring blackhole_ in the truncating iterator...
    there you go
    Victor Zverovich
    @vitaut
    Good catch! It should be easy to fix by passing the character type as an extra parameter to truncating_iterator. PRs are welcome =)
    lyngklip
    @lyngklip
    I had it working by rewriting the ++, --, * operators and adding a = operator so the truncating_iterator works more like a back_inserting_iterator, but I didn't test with plain pointers, and I I'm not quite sure what I'm doing, so...
    lyngklip
    @lyngklip
    ++(), --(), and *() for back_inserting_iterator do nothing and =() calls push_back, so the assignment actually advances the underlying iterator. I did similarly for the truncating_iterator so that --(), ++(), and *() do nothing but return *this, and assignment assigns to - and increments - the underlying iterator - if count hasn't reached limit yet. Something like if (count++ < limit) *out_++ = value;. As a template function, to avoid the issue of value_type. I'll see if I can figure out how to make a PR.
    lyngklip
    @lyngklip
    I realize that what I just wrote doesn't make sense, because back_insert_iterator doesn't have an underlying iterator. Also, if fmtlib assigns twice without advancing the iterator, my solution will fail because it will advance the iterator implicitly.
    lyngklip
    @lyngklip
    fmtlib mistakenly assumes std::strlen is constexpr for an ARM toolchain. I just removed the constexpr for the length() function.
    Victor Zverovich
    @vitaut
    What gcc version do you use?
    lyngklip
    @lyngklip
    It's a 6.3.1 that I got from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm over a year back.
    Victor Zverovich
    @vitaut
    Hmm, this is relatively new version, so it looks like an ARM toolchain thing. Is __arm__ a good macro to check?
    lyngklip
    @lyngklip
    I guess, but your guess is better than mine.
    Victor Zverovich
    @vitaut
    Should be fixed in fmtlib/fmt#889
    Rodelle Ladia
    @rLadia
    Awesome library! I was wondering if there's a way to override the on_error behavior so that I can replace the invalid format code with an empty string instead of throwing an exception.
    Victor Zverovich
    @vitaut
    Thanks! The error handling is not yet customizable via the public API but you can wrap a formatting function (such as vformat), intercept an exception and return an empty string instead.
    Marius Elvert
    @ltjax
    Hello. Is there a way to feed a dynamic number of args to fmt::format ?