[PATCH] sal_bool and String conversions

[Stephan Bergmann]

On 10/02/2012 03:01 PM, Michael Stahl wrote:
> On 02/10/12 08:33, Noel Grandin wrote:
>> Patch 7 and 11 need careful checking because they add methods to
>> OUStringBuffer and OUString.
>
>>
>> diff --git a/sal/inc/rtl/ustring.h b/sal/inc/rtl/ustring.h
>> index 5b4982e..1595c0f 100644
>> --- a/sal/inc/rtl/ustring.h
>> +++ b/sal/inc/rtl/ustring.h
>> @@ -1500,7 +1500,7 @@ SAL_DLLPUBLIC void SAL_CALL rtl_uString_newReplaceFirstAsciiLAsciiL(
>>   */
>>   SAL_DLLPUBLIC void SAL_CALL rtl_uString_newReplaceAll(
>>       rtl_uString ** newStr, rtl_uString * str, rtl_uString const * from,
>> -    rtl_uString const * to) SAL_THROW_EXTERN_C();
>> +    rtl_uString const * to, sal_Int32 fromIndex) SAL_THROW_EXTERN_C();
>>
>>   /** Create a new string by replacing all occurrences of a given substring with
>>       another substring.
>
> that is not ABI compatible.
>
>> -    OUString replaceAll(OUString const & from, OUString const & to) const {
>> +    OUString replaceAll(OUString const & from, OUString const & to, int fromIndex = 0) const {
>
> this should be source and binary compatible i think, since it's inline
> function?

Yes, changing the parameter list should be safe.  (Though the changes to 
the function's body are not, see above.)

> am unsure about this:
>
>> +    OUStringBuffer & operator+=( const OUString &str )
>> +    {
>> +        return append( str.getStr(), str.getLength() );
>> +    }
>> +
>> +    /**
>> +        Appends the string representation of the <code>char</code> array
>> +        argument to this string buffer.
>> +
>> +        The characters of the array argument are appended, in order, to
>> +        the contents of this string buffer. The length of this string
>> +        buffer increases by the length of the argument.
>> +
>> +        @param   str   the characters to be appended.
>> +        @return  this string buffer.
>> +        @since LibreOffice 3.7
>> +     */
>> +    OUStringBuffer & operator+=( const sal_Unicode * str )
>> +    {
>> +        return append( str, rtl_ustr_getLength( str ) );
>> +    }
>
>>       /**
>> +        Appends the string representation of the ASCII <code>char</code>
>> +        argument to this string buffer.
>> +
>> +        The argument is appended to the contents of this string buffer.
>> +        The length of this string buffer increases by <code>1</code>.
>> +
>> +        @param   c   an ASCII <code>char</code>.
>> +        @return  this string buffer.
>> +
>> +        @since LibreOffice 3.7
>> +     */
>> +    OUStringBuffer & operator+=(char c)
>> +    {
>> +        return append(c);
>> +    }
>
> hmmm... do we really want to have 2 sets of methods append() and
> operator+= that do the same thing, possibly with different overloads?
>
> perhaps we should deprecate the append methods... but those often have
> addition radix etc, parameters... and is it possible to chain += like
> append() in a single statement?

I would just stick to append-only for OUStringBuffer.

(Also, in general, it makes sense to keep changes to oustring/oustrbuf 
in sync with changes to ostring/ostrbuf.)

Stephan