@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.
I have a format string and a std::vector of strings that I like to use for my args
it might be useful https://github.com/fmtlib/fmt/blob/master/include/fmt/ranges.h
Yes, fmt/ranges.h is useful when you want to format a vector. For dynamic arguments take a look at fmtlib/fmt#819.
Hello! I have kinda a similar question to Rodel's one. Have you ever considered a non-aborting mode for library when you neither throw nor abort. Because when code compiles without exception support there is no way to intercept an assert.
The idea is to swallow errors (and may be report them via some custom channel) and never chash
The idea is to swallow errors (and may be report them via some custom channel) and never chash
Tests do require exceptions I believe.
An apparent change is the replacement of the
FMT_MAKE_VALUE macro with the 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?