Date: prev next · Thread: first prev next last
2019 Archives by date, by thread · List index


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.