[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