OUString's buffer is not mutable (was: Re: OUString is mutable?)

On 04/10/12 15:29, Lubos Lunak wrote:
> On Wednesday 03 of October 2012, Michael Stahl wrote:
> > On 03/10/12 18:19, Lubos Lunak wrote:
> > >  As such, as far as I can tell, immutable OUString is only a complication
> > > with no practical advantages.
> >
> > please read my other mail for other benefits...
>
>  I assume you mean the mail where you refer to std.string from the D language 
> and call it immutable because "cannot be mutated element-by-element", even 
> though there is e.g. std.string.toUp­per­In­Place() , which clearly makes it 
> mutable as far as I understand the definition of mutable. So we apparently do 
> not agree on what immutable actually means after all.

hmm i am not really familiar with "D" and just believed the first
sentence on its string documentation page :)

so let's read more of it...

> void toLowerInPlace(C)(ref C[] s);
>     Converts s to lowercase (in unicode, not just ASCII) in place. If s does not have any 
> uppercase characters, then s is unaltered.

> void toUpperInPlace(C)(ref C[] s);
>     Converts s to uppercase (in unicode, not just ASCII) in place. If s does not have any 
> lowercase characters, then s is unaltered.

these do not actually seem to operate on std.string but on arrays of
characters (presumably C is a type parameter here?).

so it appears they really mean it when they say:
>   String handling functions. Objects of types string, wstring, and
>   dstring are value types and cannot be mutated element-by-element.
>   For using mutation during building strings, use char[], wchar[], or
>   dchar[]. The *string types are preferable because they don't
>   exhibit undesired aliasing, thus making code more robust.

>  There already is OUString::operator+=, so what exactly is your definition of 
> mutable if you think OUString is mutable despite this (and, moreover, why 
> does that definition matter)?
>
>  And if you think that OUString is immutable and the operator+= is some kind 
> of mistake that should not be there, then what is the difference between 
> operator= and operator+= given that, as far as the outside world is 
> concerned, they do almost the same, except for operator+= modifying its own 
> internal copy of _rtl_uString that's not accessible from outside at the time?

>     OUString & operator+=( const OUString & str ) SAL_THROW(())
>     {
>         rtl_uString_newConcat( &pData, pData, str.pData );
>         return *this;
>     }

it allocates a new string buffer, and does not mutate the OUString's
exising buffer.

>  I do not see any problem with OUString::operator+= that OUString::operator= 
> would not already have. And since the consensus seems to be that operator= is 
> needed (and indeed OUString would be awfully cumbersome without it), then 
> operator+= can be there as well. And, by extension, a number of other 
> modifying functions.

it seems you are missing the distinction between changing which buffer
the OUString points to, and mutating elements of the buffer that an
existing OUString points to, which are separate concerns, as has already
been discussed in this thread:

On 28/09/12 13:59, Michael Stahl wrote:
> On 28/09/12 13:46, Noel Grandin wrote:
> > Hi
> >
> > I don't really understand the point of not being able to mutate OUString
> > in-place, but being able to overwrite it via the assignment operator?
> > It seems to me it should be one or the other.
> > Either OUString is immutable, and it cannot be assigned to, except via a
> > constructor, or it is mutable, and we can pretty much throw away
> > OUStringBuffer.
>
> the point you are missing is that OUString is a sort of "smart pointer"
> to an immutable buffer.  it works similarly to "String" in Java, e.g. in
> Java "String s = "foo"; s = "bar"" is legal but you cannot modify the
> content of whatever value is assigned to "s".
>
> that's why OUString has an operator= that makes it point at a different
> buffer but offers no way to write into the buffer (at least i hope it
> doesn't...).