Re: OUString is mutable?

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