detail::write in one more place relevant to printf with long argument…#2016
detail::write in one more place relevant to printf with long argument…#2016vitaut merged 4 commits intofmtlib:masterfrom
Conversation
…s, requires moving the definition of detail::write up in the file
There was a problem hiding this comment.
Thanks for the PR. This is a nice optimization but instead of replacing copy_str with write, please move the buffer handling logic from https://github.com/fmtlib/fmt/blob/master/include/fmt/format.h#L2058-L2063 to copy_str.
| template <typename Char, typename OutputIt> | ||
| OutputIt write(OutputIt out, monostate) { | ||
| FMT_ASSERT(false, ""); | ||
| return out; | ||
| } | ||
|
|
||
| template <typename Char, typename OutputIt, | ||
| FMT_ENABLE_IF(!std::is_same<Char, char>::value)> | ||
| OutputIt write(OutputIt out, string_view value) { | ||
| auto it = reserve(out, value.size()); | ||
| it = copy_str<Char>(value.begin(), value.end(), it); | ||
| return base_iterator(out, it); | ||
| } | ||
|
|
||
| template <typename Char, typename OutputIt> | ||
| OutputIt write(OutputIt out, basic_string_view<Char> value) { | ||
| auto it = reserve(out, value.size()); | ||
| it = copy_str<Char>(value.begin(), value.end(), it); | ||
| return base_iterator(out, it); | ||
| } |
include/fmt/format.h
Outdated
| template <typename Char> | ||
| buffer_appender<Char> write(buffer_appender<Char> out, | ||
| basic_string_view<Char> value) { | ||
| get_container(out).append(value.begin(), value.end()); | ||
| return out; | ||
| } |
There was a problem hiding this comment.
This overload can be removed now.
|
According to git diff origin/master...printf_long_format_arg the shifts of detail::write aren't part of the updated pull request anymore, please let me know if I'm confused here, then I'll just make a new branch for a pull request with a clean history |
|
The present specialization misses the opportunity to use buffer::append when converting between char_8 and char, but that seemed a bit tricky to get to work. Am I correct in assuming that this isn't a particularly relevant use case? |
Yes, |
|
Thank you! |
…s, requires moving the definition of detail::write up in the file
I agree that my contributions are licensed under the {fmt} license, and agree to future changes to the licensing.
The benchmark just looks at the scaling for a long string argument:
Timings on main (986fa00):
Timings on the branch (6684314):