Re: [Libreoffice] [PUSHED] Re: [PATCH] O(U)StringBuffer::toString()

On Mon, 2011-02-14 at 22:30 +0100, Sébastien Le Ray wrote:
> Actually I'm gonna start adding missing methods from
> UniString/ByteString to O(U)String and StringBuffer

There are some original design thoughts behind O(U)String FWIW, e.g
it's roughly based on the immutable java String so apart from its ctor
the methods don't change the current string, but return a new different
string when a modified string is generated. Well except for the 
operator+= wrinkle, which sort of breaks that concept. While the
UniString/ByteString is a more classic, and really fat, string class.

sal is part of the ure modules, i.e. these are the ones whose headers
are included in the SDK and third party extensions link against them.

There's the comphelper/inc/string.hxx header which includes various
helpers that didn't make it into the O(U)String class. comphelper isn't
part of UDK/SDK/URE so it's internal only. The comphelper one might in
some cases be a more convenient place to add things to, especially if
instead it would otherwise mean more symbols have to be exported from
libuno_sal.

Adding symbols to libuno_sal.so means they have to be added to the
export.map and inventing/adding a new version tag for them, i.e. OOo 3.4
will have "UDK_3.11" for the new-in-OOo-3.4 symbols, so if we need to
export something then we need something like "LO_UDK_3.4". Then if
someone builds a binary extension against LibreOffice and uses the new
symbols the extension won't work in OpenOffice.org, I don't know if we
should worry about this or not, but we should know that we're doing it.

C.