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.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
