I hacked together some type traiting for detecting the availability of
https://godbolt.org/g/dCJgEA
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
i keep getting errors of it not existing
@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
@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);
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
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%
Stripped it's still 9mb bigger
@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 ;)
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
Thanks for the suggestion. So the difference from existing named arguments API is that you can pass several arguments at once?
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
It's kind of like constructing a dictionary of named arguments.
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)."
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)
there you go
++(), --(), 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.
It's a 6.3.1 that I got from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm over a year back.