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


On 10/01/2013 05:05 PM, Matteo Casalin wrote:
     OUString provides the metod replace(sal_Unicode, sal_Unicode), which seems to be not widely used, while there are 
for sure some replaceAll("a", "b") calls here and there.
Would it be fine to rename the former to replaceAll(sal_Unicode, sal_Unicode) for consistency, fix 
the current calls and then slowly convert all of the call-places of the latter (which I think to be 
be less efficient)?
If any backward compatibility is needed, replace could be kept and just call the related replaceAll.

Not too sure that would really be worth it:

* Single-character replacement is different from multi-character replacement in that it doesn't need to specify how to handle cases where one replacement gives rise to further replacement opportunities. (That's why there originally only was a replaceFirst for the multi-character case, to avoid having to make a decision.)

* There is no support for fromIndex in replace.

* replace is an inline function, so it could be replaced (no pun intended) with "only" becoming build-time, not runtime incompatible. Keeping it around and having two inline functions doing the same trivial thing to avoid that looks like a bit too much overhead to me.

* The underlying C function is called rtl_uString_newReplace, not ..._rewReplaceAll (and /that/ couldn't be changed without breaking ABI).

Stephan

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.