summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJan Iversen <jani@documentfoundation.org>2016-03-16 00:54:38 +0100
committerJan Iversen <jani@documentfoundation.org>2016-03-16 00:54:38 +0100
commit5215695e5607db25f4ac1957395c27d00f63f409 (patch)
treeacbb0f93e6d425cde1d955391191b8d54f3deccd
parent32494e774e5e99a58ad49ce90d18c33264d0a00d (diff)
Branch libreoffice-5-1-2 libreoffice-5-1-2
This is 'libreoffice-5-1-2' - the stable branch for the 5.1.2 release. Only very safe changes, reviewed by three people are allowed. If you want to commit more complicated fix for the next 5.1.x release, please use the 'libreoffice-5-1' branch. If you want to build something cool, unstable, and risky, use master. Change-Id: I1191657ac2af2cd648ffc00fb90e768c2b6f3318
Diffstat
0 files changed, 0 insertions, 0 deletions
generated by cgit (git 2.34.1) at 2025-01-09 03:29:13 +0000
on value='feature/stub_writer'>feature/stub_writer LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/include/rtl/strbuf.hxx
AgeCommit message (Collapse)Author
2024-08-30Simplify a bitMike Kaganski
Change-Id: Icaf2e821984d9cdb16dbc4910b65b9b2b824435a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172583 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
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-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-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-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-05-06Simplify O(U)StringBuffer's append - delegate to insertMike Kaganski
This limits the number of places that know how to deal with a given type. O(U)StringNumber doesn't need an own overload, because it has operator basic_string_view. Change-Id: I6e82dc2cef103b578153fbc3ce16e96247ea9d74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151379 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-05-06Optimize O(U)StringBuffer's append/insert taking float/doubleMike Kaganski
rtl_(u)str_valueOf(Float/Double) are the most inefficient choice: their implementations call rtl_math_doubleTo(U)String, asking to allocate a new rtl_(u)String; then copy the string to the provided buffer on stack, and destroy the rtl_(u)String; and then copy the buffer into self. Even using O(U)String::number() would be more efficient, avoiding the intermediate stack buffer copy. But rtl_math_doubleTo(U)String can take also the O(U)StringBuffer's data directly, allowing to insert efficiently. Use that. Change-Id: I720ea7be6f4b2b92865a18eafcdb9ca9a089b854 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151377 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-05-06[API CHANGE] Fix O(U)StringBuffer::insert taking floatMike Kaganski
It was broken from the start: it was introduced like this already in commit 9399c662f36c385b0c705eb34e636a9aec450282 (initial import, 2000-09-18). Creating a temporary copy as a return value makes no sense. Change-Id: I6910d426c2437038ec4979be2c44cd72146dec9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151375 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
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>
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-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-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-04-15Also add C++20 char8_t overloadsStephan Bergmann
Change-Id: I1c55ca09b9fd24927acce9f0e2e2d435f23a3e42 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133031 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-13Clean up O[U]StringBuffer ctors taking a length parameterStephan Bergmann
For !LIBO_INTERNAL_ONLY, go back to the state before d91d98a53612a972de368186415aa48698e074d9 "fix gcc-4.0.1 and/or 32bit build for string literals" of having just a sal_Int32 overload. (For !LIBO_INTERNAL_ONLY, the current state was confusing, as the existence of further overloads depended on __cplusplus >= 201103L.) And for LIBO_INTERNAL_ONLY: * Have overloads for all integral types, with an assert checking that they do not use out-of-bounds length arguments. (The std::make_unsigned_t dance in the assert is needed to avoid signed/unsigned mismatch warnings as seen at least with MSVC.) This removes the need for explicitly casting arguments that are larger than (unsigned) int. (And I cleaned up two such places that I had become aware of with the abandoned previous attempt <https://gerrit.libreoffice.org/c/core/+/132825> "Let O[U]StringBuffer ctors take sal_Int32 length parameters"; there may be more places to clean up, though.) * Have deleted overloads for all integral types that are not actually integer types. (This excludes signed char and unsigned char, as at least > OUStringBuffer aBuf( rToken.GetByte()); in ScTokenConversion::ConvertToTokenSequence in sc/source/ui/unoobj/tokenuno.cxx does a legitimate call with an argument of type sal_Int8 aka signed char.) Change-Id: I2df77429f25b74f19cc3de5064e6fd982e87b05e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132951 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-13Fix copy/paste typo in commentStephan Bergmann
Change-Id: I90d350abefebf3545c47f9460627435b4a514e07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132940 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-31A string_view is not necessarily NUL-terminatedStephan Bergmann
Regression introduced into LIBO_INTERNAL_ONLY code with 1da69081732c8a429840edaaf10cfb789ea68df8 "add string_view variants of methods to O[U]StringBuffer". And add some tests. Assigning an OStringChar to an OStringBuffer also uses the std::string_view assignment operator, so also test that with testOStringChar, even though there it is relatively likely that the OStringChar temporary is followed by null bytes, which could make the test happen to erroneously succeed. But at least tools like ASan or Valgrind could catch that. On the other hand, assigning an OUStringChar to an OUStringBuffer does not use the std::u16string_view assignment operator (and rather uses a ConstCharArrayDetector-based one, which was similarly broken and has been fixed in b66387574ef9c83cbfff622468496b6f0ac4d571 "Fix -Werror=array-bounds"), so there's no test for that here. Change-Id: I7cf10ee5ce0e4280a91d116cd82d4871a0f44af6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132363 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-11In O[U]StringBuffer, make string_view params replacements for OUString onesStephan Bergmann
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That way, loplugin:bufferadd and loplugin:stringviewparam found many further opportunities for simplification (all addressed here). Some notes: * There is no longer an implicit conversion from O[U]String to O[U]StringBuffer (as that goes via user-defined conversions through string_view now), which was most noticeable in copy initializations like OStringBuffer buf = someStr; that had to be changed to direct initialization, OStringBuffer buf(someStr); But then again, it wasn't too many places that were affected and I think we can live with that. * I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to get them in line with their counterparts taking O[U]String. * I added an OUStringBuffer::lastIndexOf string_view overload that was missing (relative to OUStringBuffer::indexOf). * loplugin:stringconstant needed some addition to keep the compilerplugins/clang/test/stringconstant.cxx checks related to OStringBuffer::append and OStringBuffer::insert working. * loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related code that had been introduced in 1250aecd71fabde4dba990bfceb61bbe8e06b8ea "loplugin:stringviewparam extend to new.." Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-21string_view conversion operator for O[U]StringBufferNoel Grandin
which will be useful in an upcoming change of mine, so I don't need to construct a temporary from a buffer Change-Id: I1737a725ac5792b7d866d7f2b4c9f9ff7b50dffe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114397 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>
2021-01-28add string_view variants of methods to O[U]StringBufferNoel
and update the stringview loplugin to detect cases where we can use these new methods. Change-Id: I998efe02e35c8efcb3abfb4d7186165bbe6dfb2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110046 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-18add OStringBuffer::append(std::string_view)Noel
so we don't need to construct an OString when appending from a view Change-Id: I8105d916b43215e312857e9d9d00a38c3d833861 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107938 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-14remove unnecessary const qualifier from toStringNoel
in *StringBuffer Change-Id: Ifc1a07b2ab47d6853e3e0a39e74741b2e0b488fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107678 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>