summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRelease Engineers <releng@openoffice.org>2009-05-01 12:44:14 +0000
committerRelease Engineers <releng@openoffice.org>2009-05-01 12:44:14 +0000
commit09eb41811aa7db3014a30fa6545b0b7982adba0c (patch)
tree1b0785193cbed2d124b0f6666aa4f146ab578f40
parenta487dcd7768374d07c2295674d5204a3af19d8f6 (diff)
Create DEV300_m47 milestone tag from trunk@271426 ooo/DEV300_m47
Diffstat
0 files changed, 0 insertions, 0 deletions
generated by cgit (git 2.34.1) at 2025-01-23 04:57:46 +0000
re/slideshowprimitives LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/svl/source/items/itemprop.cxx
AgeCommit message (Collapse)Author
2024-09-11use more concrete UNO type in svlNoel Grandin
Change-Id: I794fba1f111709e0469812d48eb81cc4dc1f11d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173195 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-07-29tdf#161846 use unordered_map in SfxItemPropertyMapNoel Grandin
with large property maps, even a binary search starts showing up, but we can do a O(1) search here by using a map Change-Id: Ie7916076073e6dd393f0a1fb5a0db1b973999408 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171173 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-14loplugin:ostr in svlNoel Grandin
Change-Id: Idae670a53d6d9aab0ec7132077f3e7b7f6fa5287 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167595 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-22improve loplugin:staticmethodsNoel Grandin
Some of the exclusions were too aggressive. Restrict them to only the important classes, which exposes some more places this plugin applies. Change-Id: I1b2d1fb24391adc71ed0984f94168f61a149479f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165154 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-01-27ITEM: Cleanup some Pool stuff with DefaultsArmin Le Grand (allotropia)
Sorted out some methods at ItemPool which process Defaults to make more clear what is going on and what which method is doing. Change-Id: I2568d3e03d0a56a14b6fe4e04521e1a8e22c000b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162643 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-10-11Drop o3tl::span, can use C++20 std::span directly nowStephan Bergmann
Change-Id: Ic21ff7bf48f07f7277979d52e99d2c5c268de83f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157825 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-07-25use more o3tl::spanNoel Grandin
which means we can reserve precisely the right number of entries when building maps Change-Id: I580414699289369de4730caae09829bbd8759e82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137292 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-26avoid some allocation in SfxItemPropertySet::setPropertyValueNoel Grandin
by using std::move on the newly created poolitem, so that the pool does not need to clone it Change-Id: Ib90b14173d19768517eb2a31cc0a105e5eb4d7c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134991 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-10speed up SfxExtItemPropertySetInfoNoel Grandin
Change-Id: I7fdf0395c40f1932cfa1fc6ada91accc1912851a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115352 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-02throw() -> noexcept, part 2/3: Automatic loplugin:noexcept rewriteStephan Bergmann
Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-25loplugin:unusedmethodsNoel Grandin
Change-Id: I2d563f5f3e6e3a5f2a58080e13f4211253bdf30d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114590 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-15store ptr to the original entries in SfxItemPropertyMapNoel Grandin
instead of copying them to a new data structure that is practically identical. Helps startup time since we build a ton of these when loading documents. And use o3tl::sorted_vector as a dense map data structure to reduce allocations and improve cache friendliness, since this is a build-once thing. Change-Id: I950be03b1a21c0c81c40f2677d4215f5e8e256cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114015 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-12make SfxItemPropertySimpleEntry constructor explicitNoel Grandin
Change-Id: I09d6045320b44746fbdb103db884c214e0509a78 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114012 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-12less copying in SfxItemPropertyMap::getPropertyEntriesNoel Grandin
we can just expose the map now, and avoid copying all the properties Change-Id: Icb22975508582268dfa96e41eb98ac01e7f51317 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113982 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-12tdf#130326 flatten SfxItemPropertyMapNoel Grandin
which shaves 2% off load time here since we construct a boatload of these Change-Id: I7a57447026f3a1bd6a31f10adf15bee2d1d17c8a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113967 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-12SfxItemPropertySimpleEntry constructor should take a referenceNoel Grandin
not a pointer Change-Id: I09e356d9230e2cf386349aad028a41548cb050ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113965 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-19make *String(string_view) constructors explicitNoel Grandin
to make it more obvious when we are constructing heap OUStrings code and potentially inadvertently throwing away performance. And fix a handful of places so revealed. Change-Id: I0cf390f78026f8a670aaab53424cd31510633051 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-19use more string_view in SfxItemPropertyMapNoel
Change-Id: I053dedcbf0b110a61752722d247d6ee5e9ba481d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107977 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-13use OUStringLiteral in SfxItemPropertyMapEntryNoel Grandin
Change-Id: I4f05b6a35010e661ea77f3e4b83302d2ec74d227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100405 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-26add property name when throwing css::uno::UnknownPropertyExceptionNoel Grandin
Change-Id: I17f06c9415b9d43b6d8896360e07216c2856367a Reviewed-on: https://gerrit.libreoffice.org/79627 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-15Simplify Sequence iterations in svlArkadiy Illarionov
Use range-based loops, STL and comphelper functions Change-Id: I1c3dbf194600bec60c0881d2d19ff07b89d8333b Reviewed-on: https://gerrit.libreoffice.org/75563 Tested-by: Jenkins Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
2019-06-07tdf#42949 Fix IWYU warnings in svl/Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Except source/svdde/* which is WIN-specific Also recheck include/svl Change-Id: I32d3bcb6b14665c56c07a2f10526329b08c64cbe Reviewed-on: https://gerrit.libreoffice.org/73630 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-11-25Simplify containers iterations in svgio, svl, svtoolsArkadiy Illarionov
Use range-based loop or replace with STL functions Change-Id: I98a3e55a14c8ac00188c5003f84194c2cc6795fb Reviewed-on: https://gerrit.libreoffice.org/63959 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-27svl: Avoid unnecessary indirection in SfxItemPropertySetInfoTakeshi Abe
Change-Id: I56db3db23361590b5d2c09bc8f6f23a02ccd7f60 Reviewed-on: https://gerrit.libreoffice.org/59570 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-05-16NFC: unassigned variable pNewItem is always nullptrJustin Luth
In 2015 commit 2ebd79b3d214c62c0997606115ebc50700d6a760 a possible initialization of the variable was removed. So at this point pNewItem must return false. Change-Id: I5af9d8440463c96323c38a01f255c1dbb0113e09 Reviewed-on: https://gerrit.libreoffice.org/54395 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-12-24loplugin:passstuffbyref even more return improvementsNoel Grandin
Change-Id: I2a752025cd429e4d271626402dce5d8a8b0c76d2 Reviewed-on: https://gerrit.libreoffice.org/47021 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-23overload std::hash for OUString and OStringNoel Grandin
no need to explicitly specify it anymore Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec Reviewed-on: https://gerrit.libreoffice.org/43567 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-09-12clang-tidy modernize-use-emplace in svgio..svtoolsNoel Grandin
Change-Id: I4f3b0762e197d5397e723aba1dc43e3c857be145 Reviewed-on: https://gerrit.libreoffice.org/42193 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-08-02remove unnecessary use of 'this->'Noel Grandin
Change-Id: I5c115389af7d24c18ddaf5fbec8c00f35017a5b4 Reviewed-on: https://gerrit.libreoffice.org/40671 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-14 use more OUString::operator== in sfx2..svtoolsNoel Grandin
Change-Id: I859b77319f551eabd19dae54bd69c212221112a8 Reviewed-on: https://gerrit.libreoffice.org/39938 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>