OUString is mutable?

[Stephan Bergmann]

On 10/01/2012 12:38 PM, Michael Meeks wrote:
> On Mon, 2012-10-01 at 11:32 +0200, Noel Grandin wrote:
>> David, I agree with you - what I'm really getting at here is that it
>> seems perfectly reasonable to me to fold the functionality of
>> OUStringBuffer into OUString, making our string classes that much simpler.
>> Otherwise we're going to end up constantly converting between the two
>> for no good reason that I can see.
>
> 	I guess it'd be good to have some sample patches for tools string
> conversion showing the problem - that'd really help the discussion I
> think.
>
>> We'd have to make the following changes to struct rtl_uString:
>> - add (or steal from somewhere)  a single bit to indicate whether or not
>> the buffer field contained a read-only array of chars
>> - a 'sal_uInt32 nCapacity' field.
>
> 	Fitting that inside the ABI is going to be quite fun; then again - we
> havn't played the old game of adjusting pointers to allocate magic data
> before the struct yet I guess.

...and I hope we never do.  ;)  Really, there likely are better 
arguments in favor of a complete redesign of LO's string functionality 
than in trying to unite OUString and OUStringBuffer in a 
backwards-compatible way.  While the distinction between the two is 
arbitrary and unnecessary, that problem is IMO "well under control."

Stephan