l.lunak at suse.cz
Sun Mar 18 23:27:54 PDT 2012
On Sunday 18 of March 2012, Olivier Hallot wrote:
> Thanks Rafael
> Any suggestion for the same issue for OUStringBuffer?
First of all, what code would need such additions to OUStringBuffer? The two
classes are modeled after Java's strings, where the idea is that the normal
string is ... well, the normal string, and the buffer string is for creating
new strings. Therefore, in theory, you do not need querying functionality in
OUStringBuffer. In practice, as it happens, theory and practice are not quite
the same :). So, if justified, I don't think there'd be any practical reasons
against duplicating OUString methods in OUStringBuffer, they would be small
inline functions calling the same functionality anyway.
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 think a much better and simpler solution would be to drop the
buffer class and instead add reserve() to the string class for the cases
where it would matter. Hopefully when we can break the ABI.
Or, actually, seeing that _rtl_uString is marked as internal by the doxygen
doc, it looks like it might be doable even now. Something to add to my TODO
list for making the string classes actually nice to use :).
> Em 18-03-2012 10:46, Rafael Dominguez escreveu:
> > Theres no need, OUString already has a method lastIndexOf,
> > http://opengrok.libreoffice.org/xref/core/sal/inc/rtl/ustring.hxx#1133
> > On Sun, Mar 18, 2012 at 1:06 PM, Olivier Hallot
> > <olivier.hallot at documentfoundation.org
> > <mailto:olivier.hallot at documentfoundation.org>> wrote:
> > Hi all
> > I put forefront that I am a newbie on C++ so, forgive me if I ask things
> > too basic or dumb. I was looking into the replacement of String by
> > OUString/OUStringBuffer in some parts of the code (starmath).
> > First, I'd like a pointer on a text/discussion on why this is
> > necessary/recomended.(*)
The String class is deprecated. There's nothing to gain from having 2 classes
for the same purpose, perhaps besides headaches.
> > Secondly, as expected, some of the members of class String don't exist
> > in O[U]String[Buffer]. Therefore I was advised by Norbert to create the
> > member in the classes where I need them. So far, so good.
> > But such critical class, used all over the code, need a bit more care
> > and sponsorship, so with the specific case of
> > STRING::SearchBackward(...), is it OK to add a new member in
> > rtl::OUStringBuffer? If so, is it OK to clone STRING:SearchBackward(...)
> > to OUStringBuffer::SearchBackward(...)?
No. As said above, if the addition is justified, for consistency it should be
modeled after OUString, not String.
l.lunak at suse.cz
More information about the LibreOffice