On Friday 13 of July 2012, Christophe JAILLET wrote:
> Hi,
>
> according to my understanding,
>
> OUString::compareToAscii(RTL_CONSTASCII_STRINGPARAM("A string")) gives
compareAsciiL - the L means it gets the string length from the macro
> exactly the same result as
> OUString::compareToAscii("A string")
>
> However, the first one:
> - is harder to read
> - uses the deprecated RTL_CONSTASCII_STRINGPARAM macro
> - is a bit slower
It is actually a bit faster (the macro computes string length at
compile-time), which is presumably how this whole RTL_CONSTASCII_STRINGPARAM
madness came to be.
> If you agree with that, I will provide a patch to clean it.
String literals can now mostly be used just like OUString, because many
string functions now have specialized overloads for them. IIRC compare() does
not, for a reason I don't quite recall at the moment, but it's probably
better to leave those as they are for the time being.
> Moreover, and as a 2nd step, I plan to propose a patch that turns:
> s.compareToAscii("A string") == 0
> into
> s.equalsAscii("A string")
s.equals( "A string" )
or even simpler
s == "A string"
>
> and
>
> ! s.compareToAscii("A string")
> into
> s.equalsAscii("A string")
>
> I think that equalsAscii is better because:
> - shorter
> - more meaningful
> - doing some ! on sal_Int32 is not as clean as using sal_Bool directly
Yes, except again, just == will do.
> Do you think that such a clean-up is interesting ?
Yes, if it's interesting to you to do it :).
--
Lubos Lunak
l.lu...@suse.cz
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
