Re: OUString is mutable?

On 01/10/12 11:40, Noel Grandin wrote:
> On 2012-10-01 10:15, Stephan Bergmann wrote:
> > Note that the rtl string functionality had originally been designed, 
> > arguably somewhat naively, after java.lang.String.  On the Java 
> > platform, immutability of String is an important security measure. 
> > While that argument is irrelevant in a C/C++ context, immutability is 
> > also an important concept when reasoning about multi-threaded code. 
> > Therefore, the distinction between OUString and OUStringBuffer IMO 
> > does make sense after all.
>
> I don't see how the design helps you in a multithreaded context.
> If you share an OUString instance between two threads, either thread 
> could assign to it, replacing it's contents, and invalidating what the 
> other thread sees.

but if you share 2 copies of an OUString instance in 2 threads, they
could access the one underlying buffer concurrently without issue, and
when they want to point their copy at a different value, they can do
that independently of the other -- again, OUString works in exactly the
same way as a pointer to an immutable object here, if you copy the
pointer you can dereference it without issue and point your copy to a
different object; you only need a lock if you don't copy the pointer and
share a single pointer that one thread may update (which depending on
the situation may be necessary, say you don't just want to save memory
but actually always want the threads to point to the same value).

> So it's really not any safer than using an OUStringBuffer.
> It just gives the illusion of safety.

doesn't seem any more illusory than other things C++ programmers are
used to.