On Monday 19 of March 2012, Noel Grandin wrote:
On 2012-03-19 08:27, Lubos Lunak wrote:
That said, I myself dislike the buffer class. I doubt its
preallocation is a significant requirement for good performance
(especially given it's only 16 characters). I
Even in Java, it's a code smell to allocate a StringBuffer object
without specifying a pre-allocation size.
Might make a good EasyHack to go through the code and change the places
that allocate OUStringBuffer to give them a reasonable initial size?
It might make a good EasyHack, but otherwise it seems like a waste of effort
to me. Especially given that in some places finding out the reasonable
initial size would not be worth the cost. It would be much simpler if we
could raise the preallocation size to something more sensible, except that we
can't, since surprise surprise that overhead remains there when
OUStringBuffer::makeStringAndClear() converts it to OUString (one more reason
why the buffer classes just do not make much sense).
But let me ponder a bit more the idea of trying to get rid of the buffer
class. Next thing on my todo for string classes is the efficient operator+,
based on the proof of concept already posted to this list, which should make
a lot of usage of the buffer classes obsolete, and it would throw away some
work done for the suggested EasyHack. So I think it'd be better to evaluate
this when that work is done, seeing how much usage of the buffer class would
be there that would be actually justified. And even then, by that time, it
might be simpler to just go with OUString::reserve().
--
Lubos Lunak
l.lunak@suse.cz
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.