8f8bc0dcf3bc253ae49159d52db049767f476ced "Move string hash function into String
class" had introduced a new getHash64 that, besides returning sal_uInt64 instead
of just sal_Int32, didn't do sampling of only a handful of characters, but
always computed the hash over all characters (as the usage in SfxItemSet and
SdPage appears to require for either performance or approximated correctness).
However, it would be advantageous to keep the stable URE interface as small as
possible. Now, O(1) sampling was apparently considered state of the art when
the rtl string classes were first created, closely copying java.lang.String,
which at that time demanded sampling for hashCode(), too---but never sampling
more than 15 characters, with the obvious (in hindsight, at least) performance
catastrophes, so they changed it to O(n) somewhere along the way.
Based on that, this commit changes the existing hash functions to not do
sampling any more, and removes the newly introduced -64 variants again. (Where
the extended value range of sal_uInt64 compared to sal_Int32 was hopefully not
vital to the existing uses.)
The old implementation used sampling only for strings of length >= 256, so I did
a "make check" build with an instrumented hash function that flagged all uses
with inputs of length >= 256, and grepped workdir/{Cppunit,Junit,Python}Test for
hits. Of the 2849 hits encountered, 2845 where in the range from 256 to 295
characters, and only the remaining four where of 2472 characters. Those four
were from CppunitTest_sc_subsequent_filters_test, importing long text into a
cell, causing ScDocumentImport::setStringCell to call
svl::SharedStringPool::intern, which internally uses an unordered_set. These
results appear to justify the change.
Change-Id: I78fcc3b0f07389bdf36a21701b95a1ff0a0d970f
...to improve diagnosing misuses of boolean expressions in client code (cf.
compilerplugins/clang/implicitboolconversion.cxx). This change should be
transparent to client code.
Change-Id: Ibf43c5ded609b489952e1cc666cac1e72ffa2386
...to improve diagnosing misuses of boolean expressions in client code (cf.
compilerplugins/clang/implicitboolconversion.cxx). This change should be
transparent to client code.
Missing overloads of insert() for bool have been added to OStringBuffer and
OUStringBuffer (which required dropping one !VALID_CONVERSION check that would
now pick that overload, but would be flagged by
compilerplugins/clang/pointertobool.cxx).
Change-Id: I2d64cd923b8f47bfaa31e753def6515c29a3f8c9
Updated the documentation for the new optional second parameter in the
O(U)String startsWith* and endsWith* methods so it is explicitly said
that it is only available since LibreOffice 4.2
Change-Id: I58758e4bae85eef07c578dd50d6e0279b49deaf5
Reviewed-on: https://gerrit.libreoffice.org/6649
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
GCC 4.8.2 warns when index is a subtraction expression; the real
problems in that case will be found by the "index >= 0" check.
Change-Id: Iac2796badf88b7bdf6c273ddb800a8af0d3eaa6a
There were only a couple of real bugs fixed, but we're a little
bit safer now.
This also fixes the assert and the comment in OUString::operator[]
about this.
Change-Id: Ibe16b5794e0ba7ecd345fa0801586d25b015974c
...as there are many cases where the code later wants to obtain this part, and
esp. for the string literal variants it is awkward to calculate the length of
the literal again if this is coded with a following copy() call. Adapt some
code to use this new feature.
(Strictly speaking, the @since tags for the---backwards-compatibly---modified
functions are no longer accurate of course. Also, clean up some sal_Bool and
SAL_THROWS(()) that are unnecesssary cargo-cult here, and where the clean-up
should have no practical compatibility consequences.)
Change-Id: I43e5c578c8c4b44cb47fd08f170b5c69322ad641
It is probably best to base the functions on Unicode code points instead of
scalar values, now that they are also used from sal/rtl/strtmpl.cxx with UTF-16
code units and with arbitrary bytes (with values assumed to be a superset of
ASCII, though). Rename compareAsciiIgnoreCase to compareIgnoreAsciiCase. Also,
the corresponding tools::INetMIME functions can be removed completely; no need
to keep them around as deprecated.
Change-Id: I8d322177f4909e70a946e8186e3e0f7fa6d9a43e
Compiler plugin to replace with matching number(), boolean() or OUString ctor,
ran it, few manual tweaks, mark as really deprecated.
Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
...since gb_LinkTarget_NOEXCEPTIONFLAGS became unused with
e81b1f23c49e35c1cde1faa44281812e97be60f5 "remove
gb_LinkTarget_add_noexception_object."
Change-Id: I4a7275b5b26a9d4b6ded66efb52e6866e6e09cc3
...which has become necessary since bd60d41176da540b01d7583cfe00637431967f39
"Handle oveflow in O(U)String::toInt() functions" reduces values in the range
(SAL_MAX_INT32 .. SAL_MAX_UINT32] to zero, but some calls of toInt32(16) relied
on getting a correct (unsigned) value for the whole input range ["0" ..
"FFFFFFFF"] (see libreoffice-4-1 commit 9bf6c83367cedb7be81bf67f30d2147d26c7a8c3
"Revert overflow checks in O[U]String::toInt{32,64} again").
Audited all uses of toInt32/64 with non-decimal radix. (There is still a TODO
comment in oox/source/helper/attributelist.cxx, and
stoc/source/typeconv/convert.cxx will still need some love and test code.)
Change-Id: Iadaca1c0e41dab553687d0ce41c20c10cd657a95
(Preventing documentation of macros via @cond ... @endcond is apparently at
least broken in Doxygen 1.8.3 and working in Doxygen 1.8.4.)
Change-Id: I2ee582119dba2c3d27db5298786d3076921af46d
(Just one small fix for building against libc++, an unknown amount of
more difficult issues left to solve.)
Change-Id: I9789b8d76aa214558ab4baad823b6650ebc640d3
