search for: consume_front

On Wed, Jan 9, 2019 at 9:38 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > On Fri, Jan 4, 2019 at 3:15 PM Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> I would like to propose, based on a previous discussion on llvm-dev, >> the following change. >> https://reviews.llvm.org/D56337 >> >> The

...Ref ToolName = llvm::sys::path::filename(argv[0]); > -> 872 llvm::sys::PrintStackTraceOnErrorSignal(ToolName); > 873 llvm::PrettyStackTraceProgram X(argc, argv); > 874 > 875 // Parse arguments. > > (lldb) p ToolName.size() > (size_t) $2 = 4 > (lldb) p ToolName.consume_front(llvm::StringRef("l")) > (bool) $4 = true > (lldb) p ToolName.consume_front(llvm::StringRef("a")) > (bool) $5 = false > (lldb) p ToolName.slice(1,2) > (llvm::StringRef) $3 = (Data = "ldb", Length = 1) > > Thank you! New review online: https://revie...

...he 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 hours spent to get it all STL-ified. > > Do you consider this a blocker for doing such a split? Would it make sense to do it incremen...

...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 hours spent to get it >> all STL-ified. >> >> Do you consider this a blocker for doing such a split? Wou...

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,

...re'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 hours spent to get it >>>> all STL-ified. >>>> >>>> Do you consider thi...

...essy 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 hours spent to >>>>>> get it all STL-ified. >>>>>> >...