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.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
