RTL_CONSTASCII_USTRINGPARAM: cleanup wanted?

Michael Meeks 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 
> being.

	Ok.

> > (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.

	HTH,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot



More information about the LibreOffice mailing list