Re: OUString is mutable?

Hi Noel,

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 then we can make the OUString methods smart enough to do a 
> copy-on-write if the OUString contains a read-only buffer.

        We could do some magic there; of course - space is a bit of an issue -
we already pointlessly bloat bazillions of ascii strings into UCS-2
(nominally UTF-16) representations and nail a ref-count and length on
the beginning. If you turn on the lifecycle diagnostics in
sal/rtl/source/strimp.hxx with the #ifdef and re-build sal, you can
start to see the scale of the problem when you launch libreoffice ;-)

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

        Sure - of course, any lame thing is possible :-) however, the calling
convention of passing const references helps avoid those underlying
OUStrings being fiddled with. Naturally it's up to the caller to ensure
that a reference is held for the lifetime of the call to avoid
re-enterancy hazards; and naturally most code is quite lazy about
that ;-)

        Having said that - other threads don't just get passed strings, they
also tend to store references to them around the place; so it's
reasonably easy to have multiple OUStrings pointing to the same
rtl_uString across different threads, and the reference counting /
lifecycle semantics in theory 'just work' - and we don't have to
duplicate the strings.

        On the ninth hand - the actual use of UNO threading / apartment stuff
seems to me like something we don't want to sacrifice lots of
performance / ease-of-use / hack-ability / API cleanliness for ;-)
so ...

        Just some thoughts,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot