Apache OpenOffice (AOO) Bugzilla – Issue 75565
RFE: OStringBuffer::append( OUString, rtl_TextEncoding )
Last modified: 2007-03-21 09:21:22 UTC
It would be useful if the ::rtl::OStringBuffer had a method to append an OUString, with a given text encoding: OStringBuffer& apend( OUString const&, rtl_TextEncoding ); This could (potentially) save an allocation, which is currently needed for converting the OUString to OString, and appending the latter.
I'm somewhat undecided. For one, this borders on premature optimization. For another, you need to take care of error conditions converting from OUString to OString (characters that cannot be translated), which is most easily implemented when each function has exactly one job to do (this is similar to rtl::OUString::intern(char const*, sal_Int32, rtl_TextEncoding, sal_uInt32, sal_uInt32*) in sal/inc/rtl/ustring.hxx:1.27.52.6).
Ah, I should have known that I should not come to you with the optimization issue :) Let me rephrase: I'm too lazy to type aBuffer.append( ::rtl::OString( sString.getStr(), aString.getLength(), eSomeEncoding ) ); Instead, I'd like to type aBuffer.append( sString, eSomeEncoding ); For the second item: Sure, you need to think about error conditions. But somehow I suppose that in 80 percent of all cases (at least), the error handling will be the same with both forms: non existent. The reasons for this might even be legitimate ('cause you know the origin of the string, for instance).
aBuffer.append(rtl::OUStringToOString(sString, eSomeEncoding)); is somewhere in between character-count-wise and working today. Suits your needs? (Re error handling: The problem IMO is not so much with callers that neglect to handle errors---you can change that easily if necessary---, but with missdesigned published APIs that do not communicate error conditions properly to their callers.)
> aBuffer.append(rtl::OUStringToOString(sString, eSomeEncoding)); Hmm, could use this. Less to type, but still too much, in my very personal opinion.
Come on. :)
.