Re: OUString is mutable?

On 03/10/12 18:19, Lubos Lunak wrote:
> On Monday 01 of October 2012, Michael Stahl wrote:
> > On 01/10/12 11:40, Noel Grandin wrote:
> > > On 2012-10-01 10:15, Stephan Bergmann wrote:
> > > > 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).
>
>  Either I don't get what immutable actually means in this context (in which 
> case I'd like to be enlightened), or you are talking about things that 
> actually have nothing to do with immutability. OUString is not the same like 
> a pointer to an immutable object, because this object contains a reference 
> count (that obviously does change, for example when you point your OUString 
> copy to it). What you describe is possible with OUString, but not because of 
> immutability, but because OUString (or the internal object rather) is 
> ref-counted copy-on-write. It should be perfectly possible to have a normally 
> mutable OUString with the same abilities.

AFAIK the rtl_uString inside the OUString is mutable by itself, but the
OUString does not expose any of that mutability to its clients, which
means that for the purpose of our discussion it is in fact immutable[1].

the reference count does not fundamentally change the situation in
practice (only in theory :) because nobody who isn't insane would
manipulate it from outside of an OUString, while programmers likely
would manipulate the buffer content if it were easy to do.

... the intarwebs say that the C++ standard committee has outlawed COW
as an implementation strategy in C++11 for std::string, which is of
course mutable:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm

in any case i agree with you that this thread-safety benefit is
relatively minor and by itself not a reason to prefer immutability for
OUString, since we could just drop the reference count and always do
deep copies instead.

>  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...

> > > 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.
>
> [citation needed]

[1] of course in practice in C++ immutability can only be an illusion
and mutability is just a const_cast away...