RTL_CONSTASCII_USTRINGPARAM: cleanup wanted?
michael.meeks at suse.com
Wed Feb 22 02:25:35 PST 2012
On Tue, 2012-02-21 at 23:24 +0100, Lubos Lunak wrote:
> No, it's not yet in, but I intend to push it soon, given that there's been no
> more discussion.
Great ! :-) incidentally, I had one minor point around the ASCII vs.
UTF-8 side; the rtl_string2UString (cf. sal/rtl/source/string.cxx) does
a typically slower UTF-8 length counting loop; I suggest that we could
do better performance wise (and we do create a biggish scad of these
strings) by sticking with ascii, and doing a single, simple copy/expand
of the string. Perhaps in a new rtl_uString_newFromAsciiL method.
> Still, I want to be careful with such change that may affect pretty much
> everything, I intend to clean up first only some small places to see how it
> goes in practice, so please don't go with any mass removals for the time
> > (And it would only remove the need for
> > RTL_CONSTASCII_USTRINGPARAM in rtl::OUString constructors, not everywhere.)
> Everywhere, eventually. If it can work for ctors, it should work everywhere
> else too.
> Christina wrote:
> I wouldn't do it across the whole code base. Only if I come across
> instances of "The macro". Any objections? Of course this will be done
> in two steps "original cleanup" + "The macro cleanup".
There were some pretty -huge- changes in our build tree adding all of
these RTL_CONSTASCII_USTRINGPARAM macros ~everywhere in the recent past,
so from a 'git blame' perspective, I'd be reasonably ok with a
substantial global cleanup / replace effort here myself; I think we
already lost the history there.
michael.meeks at suse.com <><, Pseudo Engineer, itinerant idiot
More information about the LibreOffice