summaryrefslogtreecommitdiff
path: root/include/rtl
AgeCommit message (Collapse)Author
2014-02-18Stick to a single O[U]String hash functionStephan Bergmann
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
2014-02-17String cleanups.Muthu Subramanian
Change-Id: Ibebf394d69ed4845d91176727f291187ba35ed34
2014-02-13Move string hash function into String class.Muthu Subramanian
hashCode() seems to do sampling while creating the hash. hashCode64() will not. Change-Id: Id30f5a2a774cf5244dbc00da9649e95a532484be
2014-01-27Let C++ inline functions return bool instead of sal_BoolStephan Bergmann
...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
2014-01-23Let C++ inline functions return bool instead of sal_BoolStephan Bergmann
...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
2014-01-10Use proper bool operationsStephan Bergmann
Change-Id: I6aa9cf5cb7fde0a0bb2902a0b2a9e091ed6d94ab
2013-12-20typo fixesAndras Timar
Change-Id: Ia5f104bfd707bcf4e159c78ca2764c861fb0b6d9
2013-12-18URE headers do not have "using rtl::OUString"Stephan Bergmann
Change-Id: I525b93371dbd89dafa6916f7c3696423f44753f6
2013-12-10Fix addition of OStringBuffer::append(bool) overloadStephan Bergmann
...and while at it, improve generated documentation. Change-Id: I6b80b19f18cd41cd01e272bbb6e91aad2f7853f3
2013-12-10Add append(bool) to OStringBuffer.Muthu Subramanian
2013-12-10Revert unnecessary code.Muthu Subramanian
2013-12-10Fix build issue - add append(bool) to strbufMuthu Subramanian
2013-11-12rtl: starts-/endsWith* new second parameter since 4.2Andres Gomez
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>
2013-11-09fdo#65108 inter-module includes <> include/rtlNorbert Thiebaud
Change-Id: Ic90a365a237aa23846f97131146a5aa2c46b5fd2
2013-11-07OUString::operator[] silence -Werror=strict-overflow warningsMichael Stahl
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
2013-11-07OString::operator[]: make this consistent with OUStringMichael Stahl
Change-Id: If63362aba058bbcc0cc6bb1fae1c76005f1291d4
2013-11-04Convert code that calls OUString::getStr()[] to use the [] operatorNoel Grandin
This also means that this code now gets bounds checked in debug builds. Change-Id: Id777f85eaee6a737bbcb84625e6e110abe0e0f27
2013-10-23fixincludeguards.sh: include - the restThomas Arnhold
Change-Id: If1ee11da444a7f96f2d8668b277540da0bb4dbe9
2013-10-23clean up places accessing the NULL at the of an OUStringNoel Grandin
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
2013-10-15Allow starts-/endsWith* to also return the rest of the matched stringStephan Bergmann
...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
2013-09-30Clean up rtl/character.hxxStephan Bergmann
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
2013-09-30Introduce ASCII case conversion and use more/rtl/character.hxx.Arnaud Versini
Also remove all others implementations. Change-Id: I1dc108a9103f087bd8ce591dff2ac5dd254746f8 Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
2013-09-07typo fix + unwanted link fixAndras Timar
Change-Id: I65d1817e5b48f14bb8035b2f2d6daeb75100add4
2013-08-21finish deprecation of O(U)String::valueOf()Luboš Luňák
Compiler plugin to replace with matching number(), boolean() or OUString ctor, ran it, few manual tweaks, mark as really deprecated. Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
2013-08-19Introduce rtl::compareIgnoreCase and deprecate rtl/character.hxx equivalents.Arnaud Versini
Change-Id: Id90935fd2b0f904f89477792edc8140cfc31e91f Reviewed-on: https://gerrit.libreoffice.org/5412 Reviewed-by: Petr Mladek <pmladek@suse.cz> Tested-by: Petr Mladek <pmladek@suse.cz>
2013-08-14EXCEPTIONS_OFF is never definedStephan Bergmann
...since gb_LinkTarget_NOEXCEPTIONFLAGS became unused with e81b1f23c49e35c1cde1faa44281812e97be60f5 "remove gb_LinkTarget_add_noexception_object." Change-Id: I4a7275b5b26a9d4b6ded66efb52e6866e6e09cc3
2013-06-18fdo#43460 include,registry,svtools,svx,unodevtools: use isEmpty()Jelle van der Waa
Change-Id: I6e35b91092239275694eec3666b076f7ff7e54f6 Reviewed-on: https://gerrit.libreoffice.org/4335 Reviewed-by: Noel Power <noel.power@suse.com> Tested-by: Noel Power <noel.power@suse.com>
2013-06-13Introduce O[U]String::toUInt32Stephan Bergmann
...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
2013-05-29Tweak commentsStephan Bergmann
(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
2013-05-23Remove redundant (private) DO_NOT_ACQUIREStephan Bergmann
...the constructors with SAL_NO_ACQUIRE argument do the same. Change-Id: I5c893080c9ae14e9e7ecefb726f3d99fce67ec81
2013-05-15Spelling "separate" (etc) correctly is hardTor Lillqvist
2013-05-10Resolves: #i122208# introduce rtl::CStringHash and rtl::CStringEqualHerbert Dürr
unify the various c-string compares and hashes. (cherry picked from commit b7e3470a154538a92f0a21b14e726d75723f4a92) Conflicts: oox/inc/oox/export/shapes.hxx oox/source/export/shapes.cxx sal/inc/rtl/string.hxx sdext/source/minimizer/pppoptimizertoken.cxx svx/source/customshapes/EnhancedCustomShapeTypeNames.cxx vcl/source/glyphs/gcach_ftyp.cxx writerfilter/source/resourcemodel/TagLogger.cxx xmloff/source/draw/EnhancedCustomShapeToken.cxx Change-Id: Ib742744077bfb4d38a462d88b44bdef45601b4ae
2013-05-09HAVE_CXX11_PERFECT_FORWARDING doesn't seem to work against libc++Tor Lillqvist
(Just one small fix for building against libc++, an unknown amount of more difficult issues left to solve.) Change-Id: I9789b8d76aa214558ab4baad823b6650ebc640d3
2013-04-24move URE headers to include/David Tardon
Change-Id: Ib48a12e902f2311c295b2007f08f44dee28f431d Reviewed-on: https://gerrit.libreoffice.org/3499 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>