summaryrefslogtreecommitdiff
path: root/include/rtl
AgeCommit message (Collapse)AuthorFilesLines
2016-10-12Don't allow O[U]StringBuffer in string concatenationStephan Bergmann2-29/+0
...as OStringBuffer b("foo"); b = "bar" + b; doesn't work as one might expect (see the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2016-October/075464.html> "concat of OUStringBuffer". That feature was LIBO_INTERNAL_ONLY, anyway. And of the affected places, MethodDescriptor::getSignature (codemaker/source/javamaker/javatype.cxx) was the only one that would actually have benefitted. Change-Id: Ib84266f43e40c42c2e428f0c0616db8cfa90adff
2016-10-07New rtl::splitSurrogates, remove code duplicationStephan Bergmann1-0/+26
Change-Id: Ic96b64244f817196ccdfe06b97f7f31291adf372
2016-10-04@since tag; sortingStephan Bergmann1-0/+2
follow-up to 2135eae2a97c17d89cb47a2074830fd2d7b2226f "let approxEqual() not scale too early for large representable integer values" Change-Id: I628e01297fea08915d0ca1c95f3ba13f7ce15db8
2016-10-01let approxEqual() not scale too early for large representable integer valuesEike Rathke2-11/+11
And since this is now too much code for inline move implementation to math.cxx Which again made it necessary to give libreofficekit lokdocview.cxx its own implementation that doesn't even claim to build against sal ... Change-Id: I0f80be9d9172ee20693b9babde715206f2c3d8c1 Reviewed-on: https://gerrit.libreoffice.org/29428 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins <ci@libreoffice.org>
2016-09-20Related cid#1371287: Work around missing OStringBuffer move semanticsStephan Bergmann1-1/+52
...by adding more assign op overloads instead Change-Id: I3686d6c29adc47b1a8c48be4260614fd53589c8b
2016-09-20Related cid#1371289: Work around missing OUStringBuffer move semanticsStephan Bergmann1-1/+77
...by adding more assign op overloads instead Change-Id: I2d2e1b7f19d1b57528707ed5a5cce94b5fa5c2d0
2016-08-30Let OUStringLiteral1 take its arg as ctor arg, not template argStephan Bergmann2-17/+18
...which makes it more flexible, can now also be used on non-const arguments. The drawback of the argument no longer being a compile-time constant is remedied by making the ctor constexpr. Change-Id: Ia4903a2cc86791fece92eac0cb8406b6659dd19d
2016-08-30tdf#99402: fix Metafile Font handlingMike Kaganski1-0/+2
1. For DEFAULT_CHARSET/OEM_CHARSET, use correct encoding based on LibreOffice Default Language for Documents setting (Tools->Options...->Language Settings->Languages). For that, two functions added to tencinfo.h, that map language names to corresponding Windows ANSI/OEM encodings. 2. If charset is DEFAULT_CHARSET/OEM_CHARSET for Symbol font, then always use RTL_TEXTENCODING_SYMBOL. Unit test is included. Change-Id: Ibff63e7a03dec42a9d2a74399936d6bc04f2ff1a Reviewed-on: https://gerrit.libreoffice.org/28322 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-08-29Make OUStringLiteral1 a wrapper around UTF-16 instead of just ASCIIStephan Bergmann2-26/+21
...not merely an ASCII character Change-Id: Id2b381b35fe3a15574728ed973d60263dfef7249 Reviewed-on: https://gerrit.libreoffice.org/28446 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-08-29Support ConstCharArrayDetector also for UTF-16 arraysStephan Bergmann5-0/+839
The long-term benefit will be support of C++11 char16_t string literals (for cases of string literals with non-ASCII content) once we drop any compilers that don't support those yet. The short-term benefit is support for an improved OUStringLiteral1 that accepts any sal_Unicode value, not just ASCII ones (see next commit). Change-Id: I3f8f6697d7eb62b5176b7e812b5a5113c53b83a4 Reviewed-on: https://gerrit.libreoffice.org/28445 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-08-29OUString construction from OUStringLiteral1 must not be overruled by...Stephan Bergmann1-3/+14
...Except[Const]CharArrayDetector, under RTL_STRING_UNITTEST Change-Id: Ib185fb8406c4afcff1c854a2b74dae02a0ee2b3f Reviewed-on: https://gerrit.libreoffice.org/28444 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-06-14sal: rename O[U]String parameterMichael Stahl2-12/+12
Callgrind tinderbox complains that "string" shadows some global, so let's try "rString" instead. Change-Id: I3973f23ef6e8ebf861d66012fede84cb8a685be8
2016-05-13remove various crutches for boost::bind/boost::mem_fnMichael Stahl1-10/+0
These aren't used any more, and the C++11 std equivalents don't use get_pointer() overloads. Change-Id: Ib97a6a595863e21a1621c63709ea2b28f6550fde Reviewed-on: https://gerrit.libreoffice.org/24982 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2016-03-30loplugin:nullptr: Find some more cases in templatesStephan Bergmann1-1/+1
Change-Id: I1f127d56e40b04f2b4df85c0afbcfd424d68a8cc
2016-02-17Typo: namesapce(s)->namespace(s)Julien Nabet1-1/+1
Change-Id: Ic7c14c2e39a5ade1f5622a8350f9197d84cf9cc8
2016-02-15Rename rtl::isValidCodePoint -> rtl::isUnicodeCodePointStephan Bergmann1-30/+30
...and fix its documentation, and use it throughout the code base. Change-Id: I349bc2009b1b0aa7115ea90bc6ecd0a812f63698
2016-02-13tdf#81129 Support reading non-BMP characters in HTML documents.Mark Hung1-0/+13
1. Allow character entity ( &#nnnn; ) to exceed 0xffff in HTMLParser::ScanText() 2. Return a character as sal_uInt32 ( utf32 ) instead of sal_Unicode ( utf16 ) from SvParser::GetNextChar(). Conflicts: sw/qa/extras/htmlexport/htmlexport.cxx Change-Id: Ida455040970fae800f0f11471b27f53461fb78e4 Reviewed-on: https://gerrit.libreoffice.org/21152 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mark Hung <marklh9@gmail.com>
2016-01-10Fix typosAndrea Gelmini1-3/+3
Change-Id: I9a5940027423ff0791fa7da0b79b617412ce6b86 Reviewed-on: https://gerrit.libreoffice.org/21209 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
2016-01-06tdf#39631 - branch hints: comment, and tweak variously, also use.Michael Meeks2-5/+5
Find a few million mis-predicted branches (according to callgrind) and annotate them. Mark string acquire/release as hot, and a number of deprecated methods as cold. Change-Id: I678b3981794221c97f9ebb70fd0161c0fda5dceb
2015-12-20sal: make OString/OUString immovable for MSVCMichael Stahl2-0/+8
Odd problem, with MSVC 2013 in CppunitTest_smoketest in sal/osl/w32/procimpl.cxx the read_environment calls std::stable_sort, which turns about 89 elements into the empty string since commit c9f6e12e7eb6a49389360626d206191147a174fb. No idea what the problem is but let's disable the move for now. Change-Id: I2912cd54a339bb6ab39922be516ea368a430f7c9 Reviewed-on: https://gerrit.libreoffice.org/20834 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>
2015-12-17OString/OUString: move constructors and operator=Noel Grandin2-0/+64
Change-Id: Icdc5f7137cca8360f116d5d4c7b0bf4a4c526e1d Reviewed-on: https://gerrit.libreoffice.org/20712 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>
2015-12-10More loplugin:nullptr automatic rewrite (within templates)Stephan Bergmann1-4/+4
Change-Id: I9bc06cfb5eeb38fd7ae7fb25f876ea9f96e4a65a
2015-11-28Adapt to true wchar_t in clang-clStephan Bergmann1-1/+2
Change-Id: I14c2dc0be12151b5d4ea2ba3b65030f6f4494905
2015-11-18Use C++11 char16_t for sal_UnicodeStephan Bergmann1-0/+5
...in LIBO_INTERNAL_ONLY, __cplusplus, non-MSVC case. It turns out that sal_Unicode happens to not be mangled into any symbols that make up the stable URE interface, so (for LIBO_INTERNAL_ONLY, at least) we are free to replace the typedef to sal_uInt16 with a typedef to any integral type layout-compatible with that. (sal_Unicode does appear in some symbols in sal's PRIVATE_textenc.1 section, but that is private between the sal and sal_textenc libraries, so changing those symbols does not require a change of SONAME.) C++11 chart16_t is the obvious choice (and will ultimately allow using u"..." to write literals of type array-of-sal_Unicode). Reportedly, char16_t is supported since GCC 4.4 and Clang 2.9 but will only be available in MSVC 2015. For plain C, we continue to use sal_uInt16. We could theoretically use C11 char16_t from <uchar.h>, but at least the Mac OS X 10.11 SDK still does not offer that C11 header. For MSVC, we continue to use wchar_t (which is actually unsigned short, due to /Zc:wchar_t-) for now. Potential options there include dropping /Zc:wchar_t- and using true wchar_t, or using C++11 char16_t once support for MSVC 2013 is dropped. Some code needed to be adapted that was written in a way assuming that sal_Unicode is unsigned short (which indicates that changing sal_Unicode for non-LIBO_INTERNAL_ONLY would be an ABI change). OUStringBuffer::append can now differentiate between being called with sal_Unicode (to append a single character) and erroneously being called with sal_uInt16 (intending to append a number's textual representation, for which the sal_Int32 overload must be used instead). Bugs found are 379fe0409e7973b36210cffa3dd1dfd4032f0ecc "Assume that this code wants to append a number, not a character" and dc148335a6a438848325f24c49198fba81043279 "Assume this wants to append the numerical representation." The GDB support for pretty-printing of sal_Unicode-related data in solenv/gdb/libreoffice/sal.py can presumably be simplified now. Change-Id: I445b3a80e65b7cb004d9e08b38bdc9ee93bc9401 Reviewed-on: https://gerrit.libreoffice.org/20036 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2015-11-13Adapt to clang-clStephan Bergmann1-1/+2
Change-Id: I2f79e52da2aa0ad3a37aac07a36dbe14dfe401a9
2015-11-13-Werror,-Wmicrosoft-enum-valueStephan Bergmann1-1/+5
Change-Id: Iafd6e5f899835303e421be923f70d1e3f42bf65e
2015-11-10Missing includes (for NULL)Stephan Bergmann7-0/+12
Change-Id: Id2359f6ff4bddb2afbc0b346e17cd858f00179e3
2015-11-10loplugin:nullptr (automatic rewrite)Stephan Bergmann8-137/+137
Change-Id: I1bc6c87fcd6e5e96362623be94c59be216a3b2b8
2015-11-09Prevent += called on temporary O[U]String instancesStephan Bergmann2-1/+38
...found regression e31205f3ec1f941ab5a188bfde6329edf2acc55b "EditUndoRemoveChars::GetStr must return a reference" and dubious code 0e23f7b0839df68d277186b4df54ba391ac3406a "Lets assume this doesn't want to update m_pForcedPrefix->GetText() anyway" in addition to the apparent sillies directly fixed in this commit. Introduces HAVE_CXX11_REF_QUALIFIER. Change-Id: I564e98254fd53c1dd9b34193d7057c59721ee24c
2015-11-06Best avoid SAL_CALL cargo-cult for new inline functionsStephan Bergmann1-1/+1
Change-Id: Ifeaddeac673366b4eacc55ce6f2a74a2553ac927
2015-11-06rtl::Reference Add move construction/assignmentDaniel Robertson1-0/+27
Add move constructor and appropriately overloaded assignment operator to rtl::Reference, and add basic unit tests for the reference counting of rtl::Reference. Change-Id: Ia7ff5d786bdf3b17709cec06608c91e22379746c Reviewed-on: https://gerrit.libreoffice.org/19762 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2015-09-30Fix typosAndrea Gelmini3-3/+3
Change-Id: Id66432ef80fc2963fd2cbc6fad5d8e135e8975b0 Reviewed-on: https://gerrit.libreoffice.org/18956 Reviewed-by: Oliver Specht <oliver.specht@cib.de> Tested-by: Oliver Specht <oliver.specht@cib.de>
2015-09-10Add OString::startsWithIgnoreAsciiCaseStephan Bergmann1-0/+49
...analogous to the existing OUString::startsWihtIgnoreAsciiCase, to be used in the next commit Change-Id: Iad6989c16e1bda6b2b0a58e6c768f7852560bb00
2015-08-11new loplugin: defaultparamsNoel Grandin2-3/+3
find places where we do not need to be passing a parameter to a function, because that function has a default value which matches the value we are passing. Change-Id: I04d1fd6275204dd4925e6563282464f461123632
2015-08-03Fix a copy-paste errorTakeshi Abe1-1/+1
Change-Id: Ifabb905819e32cf4db603f3f7bb18e6cc8fdfdcf
2015-07-22Apply special treatment of OUStringLiteral1 to MSVC 2015David Ostrovsky1-3/+3
Change-Id: I56e69fbdb555bb30cd88d75717d6f716c81ae237 Reviewed-on: https://gerrit.libreoffice.org/16804 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2015-07-12Rule out OString(std::nullptr_t)Stephan Bergmann1-0/+5
(This is no issue for OUString, as it has two ctors taking a single pointer argument, so passing a null pointer is ambiguous anyway.) Change-Id: I36f44b29eb84eb83e284fa080d706eabb4b485d5
2015-07-08Fix typosAndrea Gelmini2-2/+2
Change-Id: I70b03c152f63e48341dc5629a99b0eeab7b497c0 Reviewed-on: https://gerrit.libreoffice.org/16834 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2015-07-03Fix typosAndrea Gelmini1-1/+1
Change-Id: Ie2bbe020fc6e3a4a4f913208c245f395849bb9ee Reviewed-on: https://gerrit.libreoffice.org/16708 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2015-06-30Coverity 1308555, 1308562, 1308600: Drop some SAL_THROW_EXTERN_CStephan Bergmann1-14/+7
...from most rtl/bootstrap.h functions. They are effectively only called from C++ code (there is no plain C UNO binding), so it should be fine to let std exceptions (like bad_alloc or length_error) propagate from their implementations to call sites. (The exception is rtl_bootstrap_args_close, which is typically called from C++ dtors, so should not throw anyway.) This would strictly speaking be an [API CHANGE], but it should make no practical difference whether a process terminates abruptly because an exception cannot pass through a SAL_THROW_EXTERN_C() nothrow specification or because legacy client code does not expect exceptions to be thrown from functions from which SAL_THROW_EXTERN_C() has now been removed. Change-Id: I08e8479e9c5731e46021aadd6a725c1793024d10
2015-06-26Add optimized OUString += literal overloadStephan Bergmann2-0/+42
Change-Id: Ib34196185f90204a71598f2c659c3fddce7a0e4d
2015-06-26SAL_WARN_UNUSED_RESULT missing from some of the operator+ overloadsStephan Bergmann1-0/+3
Change-Id: I70acf02c36ced3ff19f424768f293f2221ef7af5
2015-06-26Unnecessary nested #ifdef LIBO_INTERNAL_ONLYStephan Bergmann1-2/+0
Change-Id: I889aa10e0cb7b5779527e5ef2be5d707dd493e90
2015-06-25Revert "Revert "Generalize OUStringLiteral1""Stephan Bergmann6-199/+413
This reverts commit 5cba714b4d03ed54debf71534ad8c8edc383a01e, now including a workaround for <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53658> "internal compiler error -- segmentation fault." Change-Id: I31f6d9ddcb0b884134703df2b9dc1800ba0a84be
2015-06-24Revert "Generalize OUStringLiteral1"Stephan Bergmann6-406/+199
This reverts commit 4d4f3512db0cf0bf47c2ba1b39c3813842903ef7, at least "gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux)" fails with "include/rtl/stringutils.hxx:175:49: internal compiler error: Segmentation fault."
2015-06-24Generalize OUStringLiteral1Stephan Bergmann6-199/+406
...by making all places that accept a string literal via ConstCharArrayDetector also accept an OUStringLiteral1 via ConstCharArrayDetector (which required some tweaking of the ConstCharArrayDetector internals). That removes the need for special-purpose OUStringLiteral1 overloads, and will allow OUStringLiteral1 to be used in more places. Change-Id: I370de8480e02f8423cde5677dd38479b81bccdb2
2015-06-23Implement full set of OUString::replaceFirst/All literal overloadsStephan Bergmann2-0/+105
Change-Id: I5f525d91ce24d1d2653a6855f1c4fffc039ae398
2015-06-23Avoid conversion warnings in rtl::get[High|Low]SurrogateMatteo Casalin1-2/+2
Change-Id: I5eec1f7505e27eedd39081669011f7af42b8a26f Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
2015-06-23Avoid conversion warning in O[U]String[Buffer] constructorsMatteo Casalin4-16/+20
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>, modifying the patch to carefully keep the undefined behavior in the already existing additions that may potentially overflow, instead of making the static_cast<sal_Int32> introduction look like end - pData->buffer will be guaranteed to fit into sal_Int32 (which it is not). Change-Id: Id2fb64dc4585dae34257be6968a8905254a3b42d
2015-06-19Catch inadvertent uses of OUString(sal_Unicode) ctorStephan Bergmann1-0/+11
...with numeric values that are not meant to be characters. Inspired by <https://gerrit.libreoffice.org/#/c/16339/> "OUString: add constructor from single Unicode code point" and ecaf1cb3861c1b519a1495487fc796884cf37b92 "seems to be what was meant." Found e46e8d19458fd64ff20b1013e5eeabd07e62379c "Shall this produce a string representation of a number?" and f2a0e4032734d6be635f14ade3dea499c29ec6c2 "Don't truncate a UTF-32 code point to a UTF-16 code unit." (LIBO_INTERNAL_ONLY mostly because it uses a C++11 delegating ctor for simplicity, but also because it requires mild modifications to client code, see additional changes in this commit and some other recent commits.) Change-Id: I8a156f01d1b772c6052d7afaa088ae13ed234e2b
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-24 11:28:43 +0000