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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
