summaryrefslogtreecommitdiff
path: root/include/rtl/string.hxx
AgeCommit message (Collapse)Author
2024-09-24in OUString find functions, assert that fromIndex >= 0Noel Grandin
otherwise, the pointer calculations mean that we will start searching inside data that does not belong to the character array. which flushes out a couple of problem cases Change-Id: Ide9edf23900289343077c406d95614057c1d1a6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173807 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-08-05fix @since tagsNoel Grandin
after commit 1bbcc3fdf312971ffb681b332f47369739d95dde Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Tue May 14 14:56:47 2024 +0200 O[U]String overloads that return view for rest parameter Change-Id: Ie1d844f4286a14aa9d7cbb3831460c17103582c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171477 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-07-26Delegate match to main internal starts/endsWith*Mike Kaganski
This simplifies and deduplicates the code, and even where it was simple, it has an advantage that if a change in algorithm is decided, it is done in a single place. Change-Id: I9ec55a29c5f2b2c972ac81bf07c20fc0a52a2a8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171033 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-07-25O[U]String overloads that return view for rest parameterNoel Grandin
Add new overloads to OUString methods that have a "OUString* rest" style parameter. Instead return a view, which does not require allocation. To avoid overload ambiguity, split the methods into different variants that do not use default parameters. Change-Id: I1aa366115750f1f7ea4fe665804195f59f7c4b69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167632 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-01-24suppress COPY_INSTEAD_OF_MOVE suggestions for rtl::O[U]StringCaolán McNamara
where we have implemented move assignment to take let the compiler take advantage of any little optimization possibilities that it can take but where the potential optimization probably doesn't outweigh enforcing dusting error-prone std::move all over every case where the compiler doesn't/can't use the move assignment but could. so convert the myriad of micro optimization warnings into a single missing move assignment warning which can be then suppressed. Change-Id: I664193f9a2ac5014cf8d5134105ebd3a36857830 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162494 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-20suppress COPY_INSTEAD_OF_MOVE suggestions for uno::ReferenceCaolán McNamara
rtl::Reference, uno::Any and rtl::O[U]String where we have implemented move ctors to take let the compiler take advantage of any little optimization possibility that it can take but where the potential optimization probably doesn't outweigh enforcing dusting error-prone std::move all over every case where the compiler doesn't/can't use the move ctor but could. Change-Id: Icf184d96d3278a1740a76c7eb1150e60392351ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162337 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-07tdf#159018: make 64-bit hash algorithm similar to 32-bit oneMike Kaganski
The magic of choosing a substitution font depends on the order of fontfaces returned from PhysicalFontCollection::GetFontFaceCollection (called from WinGlyphFallbackSubstititution::FindFontSubstitute). Since commit db04b3e154a1fb8f222232ef969bb3617e051329 (return 64-bit hash for O[U]String, 2022-08-22), the order has changed, which resulted in different fallbacks in some documents (which aren't well-formed in respect to their formatting, so when they work, it's just luck). The difference was because the 64-bit hash implementation was modelled after Java one. This patch makes the code follow the algorithm in rtl::str::hashCode_WithLength, used in 32-bit hash, which restores the order (at least for my system). Not reliable, just "why not". Change-Id: I3c482e86bee79d6c9c6981300518c4ff6b7f29d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161706 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-12-04At least VS 2022 Preview 17.9.0 Preview 1.1 needs the fix tooStephan Bergmann
...from 3c6de7e20e35e37cbddd2d35e065525616deac00 "Fix build against VS 2022 17.7.5" Change-Id: I765db22aba2823e6d9a38282ac53e9ba5bcff092 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160309 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-10-19Clean up some C++20 TODOsStephan Bergmann
Change-Id: I8baece4349683c7a83a283b85e24f33874b47ba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158177 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-18Extend /clr /std:c++20 char8_t workaround to old versions of VS 2022Stephan Bergmann
On IRC, pppregin now reported that she ran into the issue addressed by 3c6de7e20e35e37cbddd2d35e065525616deac00 "Fix build against VS 2022 17.7.5" when using (a presumably old version of) VS 2022. And <https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering> suggests that older versions of VS 2022 used _MSV_VER values 1930...1936, so cover those too here. Change-Id: Ifee80114c5cd39aeabc31907adafb03eb2f388e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158122 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-18O[U]String move ctors should be constexpr, tooStephan Bergmann
...similar to 5f2206e3ccf1cf64d2b11b0e5d419973269920a8 "O{U]String copy ctor should be constexpr", which will again be useful for some upcoming replacements of OUStringConstExpr with OUString, and making data actually constexpr. (For example, the static o3tl::enumarray<INetProtocol, SchemeInfo> const map in INetURLObject::getSchemeInfo (tools/source/fsys/urlobj.cxx) can actually be constexpr, but the o3tl::enumarray ctor forwards its SchemeInfo arguments by forwarding references, so uses an implicitly generated constexpr SchemeInfo move ctor, which in turn requires constexpr member move ctors. So when the m_sScheme member will be changed from rtl::OUStringConstExpr to OUString, the OUString move ctor better be constexpr.) Change-Id: Icfc5edbb8422919186517667f876ea90bec1be90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158099 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-15Drop OStringConstExpr, use constexpr OString insteadStephan Bergmann
Change-Id: Ibb41a27fe7d5456d8db0c98821d5b2acf8586b70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-13O{U]String copy ctor should be constexprStephan Bergmann
...similar to the dtors, which will be useful for some upcoming replacements of O[U]StringLiteral and O[U]StringConstExpr Change-Id: Iad905d8466ee76eba1891fbc340073c482d568d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157944 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-13At least VS 2022 Preview 17.8.0 Preview 3.0 needs the fix tooStephan Bergmann
...from 3c6de7e20e35e37cbddd2d35e065525616deac00 "Fix build against VS 2022 17.7.5" Change-Id: I36a7d02959c5ad04781c3d484966727c3283cbbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157932 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-12Fix build against VS 2022 17.7.5Stephan Bergmann
After af9c3ed6f748781f2a77e676ffe740992788969b "__cpp_char8_t is generally available now" (which Jenkins built successfully against some VS 2019 version), various people using at least exactly VS 2022 17.7.5 (--with-visual-studio=2022) started to experience issues like > include\rtl/stringutils.hxx(251): error C2065: 'char8_t': undeclared identifier when compiling e.g. cli_ure/source/climaker/climaker_app.cxx (i.e., in /clr mode). This is similar to the VS 2019 16.11.30 /clr issue discussed in the commit message of 5a40abc86b94c0be5b4a252c6ab5b0b0df6e520d "Drop some newly obsolete __cplusplus version checks", just that it apparently hits with a different set of VS versions. The fix here is similar to the fix there, just conditionally disable char8_t functionality for certain VS versions in /clr mode, and keep fingers crossed. Change-Id: I8c4ed2e3d290dc1c94f329d314407a56170564f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157866 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11The other OStringLiteral ctor should be non-explicit tooStephan Bergmann
It had been missed by 31cd6fd0f3c856a81a03d0229de1c4d10442844f "Make OStringLiteral ctor non-explicit", and now prevented u8"..."_ostr from compiling. Change-Id: Ifb214fba0957b0d26b11daae6190ffa9d21713f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157823 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11__cpp_char8_t is generally available nowStephan Bergmann
...after 1eef07805021b7ca26a1a8894809b6d995747ba1 "Bump baseline to C++20" Change-Id: I75509f3731357e0e3ae73c3774abd6e4070f605b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157806 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-09-29Drop some newly obsolete __cplusplus version checksStephan Bergmann
...after 1eef07805021b7ca26a1a8894809b6d995747ba1 "Bump baseline to C++20". Which revealed that at least for VS 2019 16.11.30 (but not for at least VS 2022 17.7.4), in /clr mode (e.g., when compiling cli_ure/source/climaker/climaker_app.cxx), the -std:c++20 is effectively ignored, and compilation of such source files failed with > include\rtl/string.hxx(191): error C2955: 'rtl::OStringLiteral': use of class template requires template argument list > include\rtl/string.hxx(88): note: see declaration of 'rtl::OStringLiteral' > include\rtl/string.hxx(191): error C7592: a non-type template-parameter of type 'rtl::OStringLiteral' requires at least '/std:c++20' > include\rtl/string.hxx(397): error C2955: 'rtl::OStringLiteral': use of class template requires template argument list > include\rtl/string.hxx(88): note: see declaration of 'rtl::OStringLiteral' etc. To work around that, keep the 27d1f3ac016d77d3c907cebedca558308f366855 "O[U]String literals (unusable for now, C++20 only)" functionality disabled when compiling /clr sources (i.e., where _MANAGED is defined) for that old compiler. Change-Id: If62ceef5f8e55a828b880f197111fe387e4953fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157205 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-09-15StringHolder detour is only really needed for ""_tstrStephan Bergmann
Change-Id: Ifd3b21cdfa3738737b47fde0d014c312494227e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156933 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-31Introduce "..."_tstr as a companion to "..."_ostr/u"..."_ustr in template codeStephan Bergmann
...like > *path = "/"; in > template<typename T> oslFileError getSystemPathFromFileUrl( > OUString const & url, T * path, bool resolveHome) in sal/osl/unx/file_url.cxx, where T is either OString or OUString. That can now be replaced with > *path = "/"_tstr; and for OString it will be a no-cost constexpr operation, while for OUString it will still construct the OUString instance at runtime (as did the original code for both OString and OUString). (This change required moving the definition of rtl::detail::OStringHolder around in include/rtl/string.hxx. For consistency, I similarly moved around the definition of rtl::detail::OUStringHolder in include/rtl/ustring.hxx, too.) Change-Id: I7fb3a81b438f98c609684f7e70b7a60068d32fdb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154748 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-14O[U]String literals (unusable for now, C++20 only)Stephan Bergmann
Change-Id: I0ecd1a8b60a01aefdf0139e3777dc006532764fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154434 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-04-10Use of O(U)StringNumber for float/double is actually a pessimisationMike Kaganski
They use rtl_(u)str_valueOf(Float|Double), to fill the buffer, and the latter use doubleToString, which creates an rtl_(u)String, copies to the buffer, and releases the rtl_(u)String. So instead just use the rtl_(u)String from rtl_math_doubleTo(U)String directly. Even when the end result is not needed as O(U)String, this would avoid an extra copy step. Also, this avoids separate LIBO_INTERNAL_ONLY implementations. Change-Id: Ib1d9ecebd7876dfff7dc758f89ee4c1536647a50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150150 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-05Simplify O(U)String::number implementationMike Kaganski
Change-Id: I059f0324597a90aee01c95170a48ac5578f3caee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150037 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-04Make O(U)String::boolean also return an O(U)StringNumberMike Kaganski
Change-Id: I184fa0e4e45662e0fac86076d1c8733a0465bb56 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149978 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-03-27Avoid dangling references to temporary O[U]StringConcatMarker instancesStephan Bergmann
...which were created in O[U]String::Concat and bound to O[U]StringConcat::left. Thanks to Mike Kaganski for finding this. Change-Id: Id7838bc55eec7cba8860c2ec21a247bf4abd3c62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149629 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-03-17Towards literal O[U]String types in C++20Stephan Bergmann
...(where destructors can be constexpr), making 21584b304b21bfe6b99b6f29018c6b754ea28fc0 "make OUString(OUStringLiteral) constructor constexpr" and 983c1146ac80c038feae653e8e3752a72171d6cb "actually make OString(OStringLiteral) constructor constexpr" actually useful and eventually removing the need for O[U]StringConstExpr again Change-Id: I55520c1d928758f61e92336206e0f14b6f12a711 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148978 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-24Be consistent in checks for LIBO_INTERNAL_ONLYTor Lillqvist
Only check whether LIBO_INTERNAL_ONLY is defined or not. Don't check its value. If undefined, its value will default to 0, but checking the value will cause a warning that will be treated as an error if you compile with -Werror, as you should. Change-Id: I1d9e4569a016d2e6dbaa9d612071a5528ff1902e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146066 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2022-11-08A better fix for C++23 P2266R1Stephan Bergmann
After 6d6a143913603b040c10a5db83c2103557899011 "Address some of the sprintf in vcl/source/fontsubset/cff.cxx", --with-latest-c++ builds that pick up a C++23 compiler that implements <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1: Simpler implicit move" started to fail with something like > vcl/source/fontsubset/cff.cxx:2061:16: error: no viable conversion from returned value of type 'char[64]' to function return type 'OString' > return aDefaultGlyphName; > ^~~~~~~~~~~~~~~~~ [...] > include/rtl/string.hxx:313:5: note: candidate constructor [with T = char[64]] not viable: expects an lvalue for 1st argument > OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() ) > ^ etc. So I figured there should be something better than 433ab39b2175bdadb4916373cd2dc8e1aabc08a5 "Adapt implicit OString return value construction to C++23 P2266R1" (which this commit reverts, modulo its conflicts in comphelper/source/xml/xmltools.cxx and sc/source/filter/xcl97/XclExpChangeTrack.cxx) to address the underlying issue in a way that keeps code that works up to C++20 also working in C++23. (The fix is only relevant for non-explicit constructors that involve NonConstCharArrayDetector and non-const lvalue references, not for other functions involving those. OUString has a similar constructor but which is explicit, and OUStringBuffer doesn't have any similar constructors at all, so this only affects OString and OStringBuffer constructors.) Change-Id: I31cf16b9507899f5999243f8467dfa24bc94c5ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142455 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-08Address some of the sprintf in vcl/source/fontsubset/cff.cxxStephan Bergmann
...(which cause -Werror,-Wdeprecated-declarations with macOS 13 SDK), by making CffSubsetterContext::getString, and in turn CffSubsetterContext::getGlyphName, return OString. Which in turn required adding rtl::OStringConstExpr and OString::unacquired counterparts of rtl/ustring.hxx functionality to rtl/string.hxx. (It's not quite clear to me whether the nMaxLen clipping in CffSubsetterContext::getString was only there to avoid overflow of the-- somewhat arbitrarily sized?---static aNameBuf, so could go now, or rather served as a more general safety measure to not read past the mpReadPtr buffer end and should thus remain. Hence, I added a TODO comment for now.) Change-Id: I473d5a54a4be5b02917e197391e4f0982dcf690c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142412 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-10-13Deduplicate stringconcat moreMike Kaganski
In the process, drop ToStringHelper::allowO(U)StringConcat, because we can deduce this information from ToStringHelper's addData itself. To do that, addData was converted to ToStringHelper::operator(), which allows to use std::is_invocable_v on the helper class. Change-Id: Ic77878ca0ff65ada8c0a942191bc11de15b9ad2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141254 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-10-11Deduplicate O(U)StringConcatenationMike Kaganski
And use an overloaded helper function with a better (?) unified name to show that the result is not an O(U)String. Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-08-22Remove NULL-terminated requirement where not applicableMike Kaganski
These functions take the string length instead, so may take non-NULL-terminated strings. Change-Id: I21dbfd97adec197ba52ae5f9e01340b44689805b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138658 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2022-08-22return 64-bit hash for O[U]StringNoel Grandin
which gives better performance when putting strings into hashed containers that expect good key distribution. This hash implementation is the same one that Java uses. Change-Id: Iae5cf3cd27309856acfa51781295f2e56c8e77db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138574 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-29Improve some operator== involving OString,Stephan Bergmann
avoiding creation of temporary OString instances Change-Id: I27b4cb59b48b3ba40311a1f935a20250c8317d00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135093 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-09Revert "prevent using O[U]String::subView on temporaties"Stephan Bergmann
This reverts commit 59059d00c29334414a26bf5452572433f5735489, as it effectively did nothing, as rvalues can bind to `const &` just fine. <https://gerrit.libreoffice.org/c/core/+/133747> "Acutally do prevent using O[U]String::subView on temporaties" would have fixed that, but (a) it didn't find any actual mis-uses and (b) rather would have required a handful of legitimate cases to be dressed up with o3tl::temporary now, so is arguably not worth it. Change-Id: I923d0db2646dc8ea66d1b2a8b709ee2cd7a60ed4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134058 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-08prevent using O[U]String::subView on temporatiesNoel Grandin
by making the method "const &" Change-Id: I8b369ca1dd1f8d10832c85ccf3d890edb14e2c54 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132688 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-29Add back the opportunity to leave O[U]StringLiteral's buffer uninitializedStephan Bergmann
...once we have a C++20 baseline, which would render uses of the consteval O[U]StringLiteral ctors ill-formed if we accidentally failed to write to all of buffer's elements. This had been broken (and the TODO comments had become misleading) with 21584b304b21bfe6b99b6f29018c6b754ea28fc0 "make OUString(OUStringLiteral) constructor constexpr" and bca539e889d40e06cb3275442622cb075b2484a2 "make OString(OStringLiteral) constructor constexpr". Also add corresponding test code. Change-Id: I2bc680282c717d403a681ff4b9396580c8382de1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132275 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-23O[U]String::replaceAt overloads that take string_viewNoel Grandin
which results in lots of nice string_view improvements picked up by the plugins Change-Id: Ib0ec3887816b3d4436d003b739d9814f83e244b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125657 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-03A more lightweight O[U]StringConcatenationStephan Bergmann
...compared to a full-blown O[U]String, for temporary objects holding an O[U]StringConcat result that can then be used as a std::[u16]string_view. It's instructive to see how some invocations of operator ==, operator !=, and O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit materialization of an O[U]String temporary, and how that expensive operation has now been made explicit with the explicit O[U]StringConcatenation ctor. (The additional operator == and operator != overloads are necessary because the overloads taking two std::[u16]string_view parameters wouldn't even be found here with ADL. And the OUString-related ones would cause ambiguities in at least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with RTL_STRING_UNITTEST, so have simply been disabled for that special test-code case.) Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-19offsetof is only guaranteed to work with standard layout typesMike Kaganski
Change-Id: If9ba41a219d3c3b5bff838104b9a0df53030b8f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119181 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-05-18Replace rtl_string_getTokenView with o3tl::getTokenStephan Bergmann
...to not needlessly extend the sal ABI. At least for now, o3tl::getToken has a simpler interface than its OString::getToken counterpart (driven mainly by how it is used for now): it does not support a `token` argument, and its `position` argument must not be npos. To meet the latter requirement, the check for "subpath" in LineParser::readPath has been reworked slightly. Change-Id: I4428fe2d9aa03ca83a436fc6493fbc34665a8033 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115742 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-18update "add OString::getTokenView"Noel Grandin
update commit 3669d4ec43a6aa2d410d8351d631548db45a5302 Date: Fri May 14 15:51:38 2021 +0200 add OString::getTokenView (tdf#42374 related) with suggested changes from gerrit review Change-Id: I861d960deaa010740a4aa964e402c4c76a85cbc7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115706 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-15add OString::getTokenView (tdf#42374 related)Noel Grandin
small improvement to PDF import no need to construct temporary string objects when we are just to going to convert them into int/double. So use a view and convert the data through the view. Change-Id: I824fe88bf17142b48fe6032e10c0f3a111927e96 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115616 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-12Optimized OString operator += overloadsStephan Bergmann
...similar to how OUString got an operator += overload for std::u16string_view with c927aab29ebfff1ce3ac0b2f27ae343025a9890c "Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicit". In this case, though, we can easily add enough overloads (which forward to the one taking std::string_view) to avoid any ambiguities at call sites. We had left this out in the past as there is no suitable rtl_string_newConcat* function to use in the implementation, but we already had inline implementations of OStringConcat/OStringNumber overloads, so stick to that pattern here with the new std::string_view overload. Change-Id: I329036ea2b62cb921b4dbc1eef7c45a9cdb56e13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115452 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-23Remove dubious #pragma packStephan Bergmann
...that were introduced with bca539e889d40e06cb3275442622cb075b2484a2 "make OString(OStringLiteral) constructor constexpr", apparently to mimic the corresponding #pragma pack for rtl_String in include/rtl/string.h. But neither of them appear to have any value: All struct member types involved (oslInterlockedCount aka sal_Int32, sal_Int32 itself, and char) have size < 8, so the member alignment ("on a boundary that's either a multiple of [the pragma pack value], or a multiple of the size of the member, whichever is smaller", according to <https://docs.microsoft.com/en-us/cpp/preprocessor/pack?view=msvc-160>) is not affected. And neither are alignof(rtl_String) and alignof(OStringLiteral<N>) affected, which remain e.g. 4 on x86-64. (And prior to bca539e889d40e06cb3275442622cb075b2484a2, OStringLiteral did not have any pragma pack cargo cult, but which did not cause OStringLiteral::assertLayout to fail, or raise any other documented issues.) So remove the pragma pack cargo cult again at least from OStringLiteral. (And leave potential removal from rtl_String for another commit.) (This is similar to the corresponding f62cb40bdfaf41cf8e989640f9be79f652f30914 "Remove dubious #pragma pack" for OUStringLiteral.) Change-Id: I7808837a667bca717aa2e3abfdf9cb16268789ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114535 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-23actually make OString(OStringLiteral) constructor constexprNoel Grandin
doh! forgot the most important part in commit bca539e889d40e06cb3275442622cb075b2484a2 make OString(OStringLiteral) constructor constexpr Change-Id: I0c13b3b8f33f643fa72c11d8596bab70e863a879 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114529 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-23Fix --with-latest-c++ buildStephan Bergmann
...after bca539e889d40e06cb3275442622cb075b2484a2 "make OString(OStringLiteral) constructor constexpr" Change-Id: I5be28505f0222bbd4d10c7aa5233bd7346136de7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114528 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-22make OString(OStringLiteral) constructor constexprNoel Grandin
i.e. a copy of commit 21584b304b21bfe6b99b6f29018c6b754ea28fc0 make OUString(OUStringLiteral) constructor constexpr Change-Id: If5b0c2b896f8a730d01a076d3eb9161ad628979b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114480 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-19use more string_view in OString APINoel Grandin
some parts of the OString seem to have fallen behind its more popular sibling OUString. Change-Id: Ie6d64c3005b2df5da49ba79d0c38282dd5057a23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114252 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-02tdf#130978 Added comment to all published APImsrijita18
Change-Id: I744788bde9778f85ccd9d7667e19d16842900a29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110248 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-18 05:54:10 +0000