Mutable rtl::OUString?

[Stephan Bergmann]

I just received a request for enhancement
<http://www.openoffice.org/issues/show_bug.cgi?id=75224> to add some
mutating member functions to rtl::OUString.  That is an interesting issue.

As far as I can tell, rtl::OUString was originally designed as a dumb
copy of java.lang.String.  Java's String class of course is immutable,
not least for security and multi-threading reasons.  Hence,
rtl::OUString generally lacks mutating members.  The exceptions are
operator= and operator+= (I guess they were added without giving much
thought to the mutability issue, but rather just because it feels right
to have them on a C++ string class).

Now, would it make sense to have an immutable rtl::OUString in C++?
Security is definitely much less of an issue in C++ than in Java
(practically speaking, you can access all the raw memory, anyway, and
rtl::OUString makes that even easier by publicly exposing its
rtl_uString * pData).  But multi-threading is an issue, as immutable
data can be shared across threads without synchronization.  Of course,
you can set up conventions in your code, demanding that certain data is
not mutated in certain situations, but it is always nice and safe if
those conventions can actually be checked by the language.

Also, immutable rtl::OUString would fit nicely with the existence of
mutable rtl::OUStringBuffer (yet another artifact of naive Java copy, IMO).

Issue 75224 argues in favor of mutable rtl::OUString with (alleged)
resource wastage.  However, without actual measurements, it is hard to
tell whether that really is something we need to address.

Opinions anyone?

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Stephan,

> Issue 75224 argues in favor of mutable rtl::OUString with (alleged)
> resource wastage.  However, without actual measurements, it is hard to
> tell whether that really is something we need to address.

Being the one who submitted the issue, let me rephrase:
That's definately resource wastage, as code like
  sName = sName.replace( '/', '_' )
does an unnecessary allocation of memory (in case the previous pData
member is not shared, if course). Admittedly, whether this is a serious
and noticable waste is another question :).

Also, we'll have a hard time convincing people to abandon the
tools-based string (as is required by the coding guidelines) if the
to-be-substitute doesn't offer the same convenience.

Admitted, it's not too difficult to really write "sName = sName.replace"
instead of "sName.replace". But IMO, the current behaviour is not
expectation-conformant, even more for people being used to the old
string (nearly everybody whose daily work happens above the UDK, I'd
claim). Personally, I always need to code this line twice, because in
the first attempt, I forget the assignment, and wonder that it's not
working ...

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...