[Lldb-commits] [PATCH] D23884: Add StructuredData unit tests; remove JSON parsing string copy

Greg Clayton via lldb-commits lldb-commits at lists.llvm.org
Fri Aug 26 09:37:45 PDT 2016


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





More information about the lldb-commits mailing list