On 30/01/2019 22:17, Matteo Casalin wrote:
I'm working on improving code that calls getToken (e.g. using its
version with index, or using other OUString functions in its place when
possible).
One thing that I noticed is that there are a lot of calls in the form
getToken().toInt# which require memory management just to obtain a value
that could be generated by the original OUString. Similarly (but less
frequently), some tokens are extracted just to compare them against a
string, which again requires memory management that is really not needed.
I was wondering if extending O(U)String with functions like:
* getTokenAs[U]Int#(token, sep, index)
* matchToken(token, sep, index, string)
would be accepted/appreciated or not. At the moment I already submitted
to gerrit a patch [1] which adds comphelper::string::matchToken but I
think that adding such functionality to OUString directly would be
nicer. Also, introducing getTokenAsInt in OUString would likely allow to
reuse its toInt code.
Sounds a bit too special-purpose to be worth adding, IMO. Would those
optimizations really make a measurable difference?
Also, a better approach overall would probably be some string_view-based
getToken functionality (converting from an OUString to a string_view is
cheap), and then string_view-based toInt etc. functions.
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.