Fix truncation warnings in string
/vector
iterator subtraction and ranges::is_permutation
#4237
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.
Test coverage will be provided by
std/strings/basic.string/string.cons/from_range.pass.cpp
,std/containers/unord/unord.multimap/unord.multimap.cnstr/from_range.pass.cpp
, and more in the upcoming libcxx update that I'm working on. They have allocators with custom size/difference types (e.g. 32-bit types even on 64-bit platforms) that reveal these issues.When subtracting
string
/vector
iterators, we can get truncation warnings likexstring(1972): warning C4244: 'return': conversion from '__int64' to 'int', possible loss of data
. Because we're subtracting iterators into the samestring
/vector
, casting to the allocator'sdifference_type
is always safe.In
_Is_permutation_sized
poweringranges::is_permutation
, we can getalgorithm(940): warning C4244: 'argument': conversion from '__int64' to 'const int', possible loss of data
. This happens when the ranges have different difference types. We call_Is_permutation_sized
after checking that the ranges are the same length, so we only pass the first count, and casting that to the second range's difference type is guaranteed to be value-preserving. This asymmetry looked strange enough that I thought it deserved a comment (even without introducingusing _Diff2
, the line would get long enough to wrap, so we have space for a comment anyways).