> To me, both look equally wrong if OUString is considered immutable, and
> equally OK if it isn't.
Ah, but if you let your C# (or Java?) exposure influence you, foo =
foo + bar looks ok even if OUString is considered immutable. The old
object that the foo variable refered to is lost (unless it ha
On Tuesday 20 of March 2012, Caolán McNamara wrote:
> On Tue, 2012-03-20 at 15:20 +0100, Lubos Lunak wrote:
> > Before I start experimenting with more stuff in OUString that might look
> > a bit like operator+= , what exactly is so irritating about operator= or
> > operator+= in OUString and why?
On 03/20/2012 03:29 PM, Caolán McNamara wrote:
On Tue, 2012-03-20 at 15:20 +0100, Lubos Lunak wrote:
On Tuesday 20 of March 2012, Caolán McNamara wrote:
On Mon, 2012-03-19 at 13:39 +0100, Stephan Bergmann wrote:
(And even if immutable classes are
generally also a good idea in C++, esp. in comb
> It's just that if OUString was supposed to be immutable, then a
> foo += bar; "feels wrong" to me in some vague way that, I guess
> bizarrely, foo = foo + bar doesn't.
Ditto.
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://
On Tue, 2012-03-20 at 15:20 +0100, Lubos Lunak wrote:
> On Tuesday 20 of March 2012, Caolán McNamara wrote:
> > On Mon, 2012-03-19 at 13:39 +0100, Stephan Bergmann wrote:
> > > (And even if immutable classes are
> > > generally also a good idea in C++, esp. in combination with
> > > multi-threading
On Tuesday 20 of March 2012, Caolán McNamara wrote:
> On Mon, 2012-03-19 at 13:39 +0100, Stephan Bergmann wrote:
> > (And even if immutable classes are
> > generally also a good idea in C++, esp. in combination with
> > multi-threading, the mutable rtl::OUString::operator= spoils this,
> > anyway.)
On Mon, 2012-03-19 at 13:39 +0100, Stephan Bergmann wrote:
> (And even if immutable classes are
> generally also a good idea in C++, esp. in combination with
> multi-threading, the mutable rtl::OUString::operator= spoils this, anyway.)
And the += operator irritates me.
Either way though, its a
On Mon, 2012-03-19 at 15:05 +0100, Michael Stahl wrote:
> hmm... what i'd really like from a string class is that it has no
> operator[] at all (who needs that anyway), just an iterator interface
> that returns characters as uint32_t
I'm personally somewhat skeptical that, even at a uint3
> the historical reason is that std::string is part of the C++
> standard
> library, and implementations of that generally only started to
> become
> actually usable on all platforms in the early 2000s.
Okay, that shouldn't be an real argument, when we're talking about
refactoring anyways ;-)
>
On 03/19/2012 04:15 PM, Noel Grandin wrote:
Wouldn't need to be perfect,
...but *would* need to take care to not overflow sal_Int32's positive
range (which is the source of potential complication here).
Stephan
___
LibreOffice mailing list
LibreOff
On Mon, Mar 19, 2012 at 16:05, Michael Stahl wrote:
> hmm... what i'd really like from a string class is that it has no
> operator[] at all (who needs that anyway), just an iterator interface
> that returns characters as uint32_t, and another interface to write the
> string UTF-8 encoded into some
On Mon, Mar 19, 2012 at 14:46, Stephan Bergmann wrote:
> On 03/19/2012 07:30 AM, Noel Grandin wrote:
>> Might make a good EasyHack to go through the code and change the places
>> that allocate OUStringBuffer to give them a reasonable initial size?
>
>
> around, it is often not easy to write an exp
On 19/03/12 09:50, Enrico Weigelt wrote:
> Hi folks,
>
>
> I just went into this list and wonder why lo has its own string
> implementation instead of using std::string. Could anyone
> please give me some insight ?
the historical reason is that std::string is part of the C++ standard
library, an
On Monday 19 of March 2012, Stephan Bergmann wrote:
> On 03/19/2012 07:27 AM, Lubos Lunak wrote:
> > 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 a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Lubos, all...
Em 19-03-2012 03:27, Lubos Lunak escreveu:
> 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
On 03/19/2012 07:27 AM, Lubos Lunak wrote:
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
On Monday 19 of March 2012, Tor Lillqvist wrote:
> > insight ?
>
> History?
Possibly, if history of std::string is meant.
(Bonus points to whoever can write the equivalent of
str.replaceAll( "foo", "bar" ) with std::string from the top of the head.
Extra extra bonus points if the code fits to
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
> insight ?
History?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On 03/19/2012 07:30 AM, Noel Grandin wrote:
Even in Java, it's a code smell to allocate a StringBuffer object
without specifying a pre-allocation size.
Is it?
Might make a good EasyHack to go through the code and change the places
that allocate OUStringBuffer to give them a reasonable initial
Hi folks,
I just went into this list and wonder why lo has its own string
implementation instead of using std::string. Could anyone
please give me some insight ?
cu
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedeskto
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 specifyin
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
Well OUStringBuffer dont seems to be the correct class to add that type of
functionality, but maybe someone else
can point you in the right direction.
On Sun, Mar 18, 2012 at 1:45 PM, Olivier Hallot <
olivier.hal...@documentfoundation.org> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks Rafael
Any suggestion for the same issue for OUStringBuffer?
Kind regards
Ikuvuer
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/i
On 18.03.2012 17:46, Rafael Dominguez wrote:
Theres no need, OUString already has a method lastIndexOf,
added to the wiki :)
Regards,
Ivan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/l
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.hal...@documentfoundation.org> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all
>
> I put
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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/discu
28 matches
Mail list logo