clayborg added a comment. In https://reviews.llvm.org/D23884#526390, @zturner wrote:
> Actually it looks like `JSONParser` constructor takes a `StringRef` and then > converts it to a `std::string` internally. Why can't it just store the > `StringRef` internally? It doesn't modify the buffer, and incidentally it > also keeps a `uint64_t` representing the "offset" into the string. That's > what a `StringRef` is. an immutable buffer and an offset. Each time you > extract something, you just say `m_buffer = m_buffer.drop_front(n)`. Yep, we just need to create a StringRefExtractor class that uses a llvm::StringRef class internally instead of a std::string. If you do something about this, don't change StringExtractor since all of the GDB remote packets use these and actually use the std::string as the backing store for all of its incoming packets. > There is the `SetFilePos()` method, but it looks like it's only being used > for two purposes: 1) To move forward, and 2) To reset the position to 0 > after setting a new string in the extractor. The first one is still possible > with a `StringRef` by writing `extractor.skip(n)`, and the second one is > still possible by writing `extractor.SetString(NewStringRef)`. You don't want to modify the string in any way. StringRefExtractor would contain a llvm::StringRef + the current offset position just like StringExtractor. No need to change anything functionality wise. Again, if we switch the parser over to use an llvm::StringRef then this make sense, otherwise it doesn't. https://reviews.llvm.org/D23884 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
