--- misc/build/boost_1_44_0/boost/config/compiler/visualc.hpp +++ misc/build/boost_1_44_0/boost/config/compiler/visualc.hpp @@ -101,6 +101,11 @@ # define BOOST_NO_ADL_BARRIER #endif +#if _MSC_VER >= 1700 // 1700 == VC++ 11.0 + // Removed in VC11: +# define BOOST_NO_0X_HDR_INITIALIZER_LIST +#endif + #if (_MSC_VER <= 1600) // MSVC (including the latest checked version) has not yet completely @@ -269,8 +269,8 @@ #error "Compiler not supported or configured - please reconfigure" #endif // -// last known and checked version is 1600 (VC10, aka 2010): -#if (_MSC_VER > 1600) +// last known and checked version is 1700 (VC12, aka 2012): +#if (_MSC_VER > 1700) # if defined(BOOST_ASSERT_CONFIG) # error "Unknown compiler version - please run the configure tests and report the results" # else distro/CN/libreoffice-7-4-LTS'>distro/CN/libreoffice-7-4-LTS LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/svx/source/form/fmobjfac.cxx
AgeCommit message (Collapse)Author
2022-08-29ref-count SdrObjectNoel Grandin
Which means we can get rid of the majestic hack of ScCaptionPtr Previously, SdrObject was manually managed, and the ownership passed around in very complicated fashion. Notes: (*) SvxShape has a strong reference to SdrObject, where previously it had a weak reference. It is now strong since otherwise the SdrObject will go away very eagerly. (*) SdrObject still has a weak reference to SvxShape (*) In the existing places that an SdrObject is being deleted, we now just clear the reference (*) instead of SwVirtFlyDrawObj removing itself from the page that contains inside it's destructor, make the call site do the removing from the page. (*) Needed to take the SolarMutex in UndoManagerHelper_Impl::impl_clear because this can be called from UNO (e.g. sfx2_complex JUnit test) and the SdrObjects need the SolarMutex when destructing. (*) handle a tricky situation with SwDrawVirtObj in the SwDrawModel destructor because the existing code wants mpDrawObj in SwAnchoredObject to be sometimes owning, sometimes not, which results in a cycle with the new code. Change-Id: I4d79df1660e386388e5d51030653755bca02a163 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138837 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-18Move tools/diagnose_ex.h to comphelper/diagnose_ex.hxxStephan Bergmann
...so that its TOOLS_WARN_EXCEPTION can be used in comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it, rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The comphelper module is sufficiently low-level for this immediate use case, so use that at least for now; o3tl might be even more suitable but doesn't have a Library until now. Also, for the immediate use case it would have sufficed to only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION, TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of include/tools/diagnose_ex.h into an additional new include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move the complete include file as is.) Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-03Just use Any ctor instead of makeAny in svxStephan Bergmann
Change-Id: I59b1b3f817a9028f132456ea5094f38f88674d00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133768 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-11new loplugin:trivialdestructorNoel Grandin
look for potentially trivial destructors that can then be elided Change-Id: I435c251bd4291b5864c20d68f88676faac7c43fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131318 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-01-07remove E3D_INVENTOR_FLAG and convert SdrObjKind to scoped enumNoel Grandin
We don't need E3D_INVENTOR_FLAG, we can just check if the SdrObjKind is in the right range. Which exposes some dodgy code in DrawViewShell::GetMenuStateSel SfxItemState::DEFAULT == rSet.GetItemState( OBJ_TITLETEXT ) || SfxItemState::DEFAULT == rSet.GetItemState( OBJ_OUTLINETEXT ) || which has been there ever since commit f47a9d9db3d06927380bb79b04bb6d4721a92d2b Date: Mon Sep 18 16:07:07 2000 +0000 initial import just remove that. In SwFEShell::ImpEndCreate() move some logic around to avoid using an out-of-range SdrObjKind value Change-Id: I4620bfe61aca8f7415503debe3c84bfe5f4368a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127763 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-24make it possible to build required database stuff for fuzzingCaolán McNamara
The dbase filter requires dbaccess and connectivity but I don't want to pull in the rest of the stuff that --disable-database-connectivity currently disables that we still don't need for fuzzing if --disable-database-connectivity is removed Change-Id: Ia48d42295f9724b4dd2d3beb8e46ed23fc789f5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122579 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-06make SdrObject Identifiers SdrObjKind enum membersCaolán McNamara
with unique values so that, e.g. if (pObj->GetObjIdentifier() == OBJ_LINE) is only true if pObj is a SdrPathObj and not a E3dScene Change-Id: I30c91e57eb27141390c644dec42e2a4bee96edf0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105374 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-02-24tdf#42949 Fix IWYU warnings in svx/source/[f-m]*/*cxxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I103c5c7f1a74e8c3a021a91c7a96ebc87cb19efd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89263 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-12-26use more TOOLS_WARN_EXCEPTIONNoel Grandin
so we get more useful log messages when stuff goes wrong Change-Id: Ia55db7ab1a4d79b0f281673fbbb06c61745fa89e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85829 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>