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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
