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.
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice