summaryrefslogtreecommitdiff
path: root/sw/inc/crsrsh.hxx
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2017-03-02 08:35:18 +0100
committerStephan Bergmann <sbergman@redhat.com>2017-03-02 10:06:34 +0000
commit2fdd5760b402f9e0a8c829bc8aa05c618afc674a (patch)
treea2bfb95c513a43df0050f70373641eb56f0b9f25 /sw/inc/crsrsh.hxx
parent64cca8d6237ef90c3b222df36de257dbb859d99e (diff)
Complete the transition of SwRedlineTable::size_type
...from 9ca8a63fff65acf2ea13b391495ad232f4636548 "Use consistent integer types in the SwRedlineTable interface". This all started as an attempt to reduce the number of places a to-be-committed improved loplugin:loopvartoosmall complains about. Lets see where it ends... SwRedlineTable::size_type is now the size_type of the underlying std::vector, no longer sal_uInt16 from ancient times. I tried hard to find all places that are affected by this change, changing types of affected variables and non-static data members as needed. Some notes: * The original code used USHRT_MAX as a "not found" value. I replaced that with a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for now of value USHRT_MAX. This should eventually be changed to something more sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is best done after we have constexpr support in all toolchains, so that npos can be constexpr). It is important that the value of npos is towards positive infinity, as many places in the code use for (i = f(); // may return npos i < table.size(); ++i) table[i] ... * There are some borders where values of SwRedlineTable::size_type are converted into different types, for various reasons. But all of those other types should be large enough for practical purposes (at least 32 bits wide): MakrEntry::m_nIdx: long int SvxRedlinTable::InsertEntry: sal_uIntPtr nPos SwRangeRedline: size_t SwRedlineItr: sal_Int32 SwVbaRevision::GetPosition: sal_Int32 SwXRedlines: sal_Int32 * .uno:TrackedChangeIndex= transports textual representations of such values. libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as strings, while SwTiledRenderingTest converts them to int. * TODO: The one place I'm unsure about is SfxUInt16Items with IDs FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE in sw/source/uibase/uiview/view2.cxx. For now, I kept those as SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from those items. But I have no idea where instances of those items would actually be created, and what it would mean to change those items' types? Change-Id: Ib7a14dc67e2b970766966e43f4732abd9f045ff8 Reviewed-on: https://gerrit.libreoffice.org/34775 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Diffstat (limited to 'sw/inc/crsrsh.hxx')
-rw-r--r--sw/inc/crsrsh.hxx5
1 files changed, 3 insertions, 2 deletions
diff --git a/sw/inc/crsrsh.hxx b/sw/inc/crsrsh.hxx
index 2b03f7bbb734..ef2e9539859c 100644
--- a/sw/inc/crsrsh.hxx
+++ b/sw/inc/crsrsh.hxx
@@ -28,6 +28,7 @@
#include <IShellCursorSupplier.hxx>
#include "swdllapi.h"
+#include <docary.hxx>
#include <swtypes.hxx>
#include <viewsh.hxx>
#include <calbck.hxx>
@@ -267,7 +268,7 @@ private:
typedef bool (SwCursor:: *FNCursor)();
SAL_DLLPRIVATE bool CallCursorFN( FNCursor );
- SAL_DLLPRIVATE const SwRangeRedline* GotoRedline_( sal_uInt16 nArrPos, bool bSelect );
+ SAL_DLLPRIVATE const SwRangeRedline* GotoRedline_( SwRedlineTable::size_type nArrPos, bool bSelect );
protected:
@@ -797,7 +798,7 @@ public:
const SwRangeRedline* SelNextRedline();
const SwRangeRedline* SelPrevRedline();
- const SwRangeRedline* GotoRedline( sal_uInt16 nArrPos, bool bSelect );
+ const SwRangeRedline* GotoRedline( SwRedlineTable::size_type nArrPos, bool bSelect );
// is cursor or the point in/over a vertical formatted text?
bool IsInVerticalText( const Point* pPt = nullptr ) const;