summaryrefslogtreecommitdiff
path: root/common/StringVector.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-06-02wsd: optimized tokenizationAshod Nakashian1-19/+0
Change-Id: I79b5117b89c982c15cee5c1e230a44785059affd Reviewed-on: https://gerrit.libreoffice.org/c/online/+/95336 Tested-by: Jenkins Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
2020-06-02wsd: optimize StringVectorAshod Nakashian1-71/+2
StringVector is heavily used for tokenization and benefits from inlining of small functions. Also, cat doesn't need to be slower than necessary. Change-Id: I4ab2ff1b1f1a81092049d2cde64b6df10b34b5f7 Reviewed-on: https://gerrit.libreoffice.org/c/online/+/95287 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Jenkins
2020-03-09Introduce StringVector::equals()Miklos Vajna1-0/+30
Allows comparing tokens with C strings without a heap allocation. Do the same when comparing two tokens from two different StringVectors. And use it at all places where operator ==() has an argument, which is a StringVector::operator []() result. Change-Id: Id36eff96767ab99b235ecbd12fb14446a3efa869 Reviewed-on: https://gerrit.libreoffice.org/c/online/+/90201 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-03-02StringVector: fix build with gcc-4.9Miklos Vajna1-3/+3
Debian 8 has gcc-4.9, which emits -Werror in case a parameter and a member function has the same name. Given that we also use -Werror unconditionally, this breaks the build. Newer gcc/clang versions relaxed this warning, so this was not a problem in those cases. Change-Id: I7ad09370d96aa7384b2c117dd8de421644898b50 Reviewed-on: https://gerrit.libreoffice.org/c/online/+/89785 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-02-28Rework StringVector to have a single underlying stringMiklos Vajna1-12/+56
This is meant to reduce lots of small allocations and instead have pointers into the single string for the various tokens instead. This has a few requirements, though: 1) It's no longer OK to modify the tokens, changing their length would invalidate the start/length of other tokens. Rework DocumentBroker::load() to avoid such mutation. 2) The iterators no longer expose zero-terminated strings, so Poco::cat() doesn't work anymore: add an own cat() instead and use that in e.g. ChildSession. The own cat() has the benefit that it won't read past the end of the array if the begin index is out of bounds to add more safety. (This nicely works towards killing Poco usage in general.) 3) If zero-terminated strings for all individual tokens is needed, a copy has to be made, as done in spawnProcess(). (For all of these requirements, the build fails if there are problems.) Change-Id: Iea40e4400e630b2d669f5c72aea85cb40edf9a2c Reviewed-on: https://gerrit.libreoffice.org/c/online/+/89711 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-02-28Rework LOOLProtocol::tokenize() to return a StringVector objectMiklos Vajna1-0/+45
The bulk of this commit just changes std::vector<std::string> to StringVector when we deal with tokens from a websocket message. The less boring part of it is the new StringVector class, which is a wrapper around std::vector<std::string>, and provides the same API, except that operator[] returns a string, not a string&, and this allows returning an empty string in case that prevents reading past the end of the underlying array. This means in case client code forgets to check size() before invoking operator[], we don't crash. (See the ~3 previous commits which fixed such crashes.) Later the ctor could be changed to take a single underlying string to avoid lots of tiny allocations, that's not yet done in this commit. Change-Id: I8a6082143a8ac0b65824f574b32104d7889c184f Reviewed-on: https://gerrit.libreoffice.org/c/online/+/89687 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>