search for: drop_front

...================================ --- tools/lld/lib/ReaderWriter/LinkerScript.cpp (revision 8570c61c3fce7de2f655a20f8b184efa1bd97c00) +++ tools/lld/lib/ReaderWriter/LinkerScript.cpp (revision ) @@ -2557,7 +2557,7 @@ switch (*j) { case '*': while (!wildcardMatch(pattern.drop_front(j - pattern.begin() + 1), - name.drop_front(i - name.begin() + 1))) { + name.drop_front(i - name.begin()))) { if (i == name.end()) return false; ++i; @@ -2565,6 +2565,7 @@ break; case '?':...

...derWriter/LinkerScript.cpp (revision >> 8570c61c3fce7de2f655a20f8b184efa1bd97c00) >> +++ tools/lld/lib/ReaderWriter/LinkerScript.cpp (revision ) >> @@ -2557,7 +2557,7 @@ >> switch (*j) { >> case '*': >> while (!wildcardMatch(pattern.drop_front(j - pattern.begin() + 1), >> - name.drop_front(i - name.begin() + 1))) { >> + name.drop_front(i - name.begin()))) { >> if (i == name.end()) >> return false; >> ++i; >> @@ -2565,6 +...

...; On Jul 5, 2017, at 5:07 PM, Zachary Turner <zturner at google.com> wrote: > > Re-writing StringRef / ArrayRef etc to use the exact same API is a good idea long term, but there's a lot of ugly messy details that need to be dealt with. There's thousands of uses of take_front / drop_front, etc that have to be converted. Then there's some methods that aren't in string_view at all, like consume_integer(), consume_front(), etc that would have to be raised up to global functions in StringExtras. All of this can certainly be done, but it's going to be a *ton* of churn and h...

...PM, Zachary Turner <zturner at google.com> wrote: >> >> Re-writing StringRef / ArrayRef etc to use the exact same API is a good >> idea long term, but there's a lot of ugly messy details that need to be >> dealt with. There's thousands of uses of take_front / drop_front, etc that >> have to be converted. Then there's some methods that aren't in string_view >> at all, like consume_integer(), consume_front(), etc that would have to be >> raised up to global functions in StringExtras. All of this can certainly >> be done, but it'...

Yes, that proposal makes sense to me: the split would be between things that *are* known to be subsumed into later versions of C++, and therefore are a compatibility library. What do you think about this as an implementation approach: - Rewrite StringRef (et al) to use the exact same APIs as std::string_view. Keep the StringRef name for now. - When cmake detects that C++’17 mode is supported,

...at google.com> wrote: >>>> >>>> Re-writing StringRef / ArrayRef etc to use the exact same API is a good >>>> idea long term, but there's a lot of ugly messy details that need to be >>>> dealt with. There's thousands of uses of take_front / drop_front, etc that >>>> have to be converted. Then there's some methods that aren't in string_view >>>> at all, like consume_integer(), consume_front(), etc that would have to be >>>> raised up to global functions in StringExtras. All of this can certainly >&...

...;>>>> >>>>>> Re-writing StringRef / ArrayRef etc to use the exact same API is a >>>>>> good idea long term, but there's a lot of ugly messy details that need to >>>>>> be dealt with. There's thousands of uses of take_front / drop_front, etc >>>>>> that have to be converted. Then there's some methods that aren't in >>>>>> string_view at all, like consume_integer(), consume_front(), etc that would >>>>>> have to be raised up to global functions in StringExtras. All of...

...st), last(last) {} + string_ref() : first(nullptr), last(nullptr) {} + + string_ref substr(size_t from, size_t to) { + if (to >= size()) to = size() - 1; + if (from >= size()) from = size() - 1; + return string_ref(first + from, first + to); + } + + string_ref drop_front(size_t n) const { + if (n >= size()) n = size() - 1; + return string_ref(first + n, last); + } + + bool starts_with(string_ref str) const { + if (str.size() > size()) + return false; + return std::equal(str.begin(), str.end(), begin()); + } + +...