On Sun, Dec 2, 2012 at 4:56 PM, Lubos Lunak <l.lu...@suse.cz> wrote: > > Hello, > > The work is based on threads [1] and [2] and occassionally seeing in the > commits that people doing string cleanups sometimes change ugly code to only > slightly less ugly code. With the new feature enabled, any string > concatenation/creation is simply done as (well, ok, the number() part is not > done yet, but shouldn't be difficult to add): > > OUString s = foo + bar + "baz" + OUString::number( many ) + "whatever"; > > All the other alternatives, like explicit OUStringBuffer and repeated append() > should be now worse in all possible aspects.
What is the recommended way to deal with for() { } In fact, this should result in > just one OUString allocation, one data copy for anything and at most one > length computation, so it should possibly beat even strcpy+strcat, while at > the same time looking good. > > I successfully built with gcc (not the ancient Apple one though, I intend to > pass there again), clang and msvc2010 and passed 'make check'. The resulting > binary size is about the same (funnily enough it seems that gcc's -Os stops > it from fully inlining, preventing it from optimizing out more stuff and > making the code smaller). > > Even though this is in sal/, the intention is to keep this code LO-internal, > so there won't be any BIC problems, 3rd party apps will keep getting the > original code. All O(U)String code is inline functions, so there shouldn't be > any trouble there. > > So as you can see, this would be perfect, if it weren't for some small > gotchas: > - since operator+ now returns a different object, this is not entirely source > compatible, and explicit conversions to O(U)String may need to be added > (e.g. '( a + "b" ).getStr()' -> 'OUString( a + "b" ).getStr()' ). If some of > those cases would be too annoying, I can try harder to avoid them, but some > are unavoidable ( ?: operator being one of them and somewhat vexing). However > the patch 0005 patch fixing all such issues in LO is pretty small, so this > does not currently seem to be an issue (although that may be because the idea > of writing simple string-handling code may be catching up slowly). > - as it is template-based, error messages can get somewhat longer, but IMO > it's nothing horrific. Compilers with decent error reporting are > recommended :). Alternatively, temporary "#define RTL_DISABLE_FAST_STRING" at > the top of the source file should help too. > > Still, I think it works pretty well. > > [1] > http://lists.freedesktop.org/archives/libreoffice/2011-November/021156.html > [2] > http://lists.freedesktop.org/archives/libreoffice/2011-December/022323.html > > -- > Lubos Lunak > l.lu...@suse.cz > > _______________________________________________ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice