Use contiguous_range when available#4716
Open
user202729 wants to merge 1 commit intofmtlib:masterfrom
Open
Conversation
713d88f to
e668131
Compare
e668131 to
b325412
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This provides further 20% speedup for
vector<char>when used on top of #4679 (with the linked benchmark that has since then been rejected, but for the purpose of measuring the code runtime, it works well enough), for understandable reasons.If one wants support for faster format to
vector<char>before C++20, it's possible to specializeis_contiguousforvector,arrayetc. But I don't think it's worth it. For example, such template specialization would not work with custom string types.I don't know if
<ranges>is too heavy forbase.h. There iscontiguous_iteratorinstead in<iterator>. https://en.cppreference.com/w/cpp/iterator/contiguous_iterator.htmlSide note, thinking about it, since
base.hdefinesis_contiguousto be always false, butformat.hdefines it to be true forstring, wouldn't this lead to potential ODR?Aincludes onlybase.hand use (something that uses)is_contiguous<string>.Bincludesformat.hand use (something that uses)is_contiguous<string>.In practice, it's probably fine though.