[Libreoffice-bugs] [Bug 138109] New: Create and use a dedicated Length C++ type

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Tue Nov 10 10:20:57 UTC 2020


https://bugs.documentfoundation.org/show_bug.cgi?id=138109

            Bug ID: 138109
           Summary: Create and use a dedicated Length C++ type
           Product: LibreOffice
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Keywords: difficultyMedium, easyHack, skillCpp
          Severity: normal
          Priority: medium
         Component: LibreOffice
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: mikekaganski at hotmail.com
                CC: caolanm at redhat.com, michael.stahl at cib.de,
                    quikee at gmail.com, sbergman at redhat.com,
                    vmiklos at collabora.com

We use length measures intensively throughout the codebase. We use millimeters,
inches, hundreds of mm, cm, m, twips, points, EMUs, and many others. We convert
those in all directions.

I suggest to create a dedicated class (in tools?) that would represent generic
length; consistently using such class in the code would allow to minimize
rounding errors from repeated conversions (there should ideally be only two
conversions: when a length is read from a file, and when it's output), and
prevent confusion when a number (representing a length) is received from some
function, and it's hard to know what units should be used with the number.

It possibly should use some fixed internal unit for length, and some fixed type
for the value. It should provide convenience static and member functions for
conversion to/from different units, which would also provide overloads for
different resulting typed (esp. to differentiate floating-point results vs
integer results, with rounding for the latter). It should also provide
user-defined literals for simplifying definitions of things like 2_mm or
25_EMU. It needs to allow usual arithmetical operations.

Subject to discussion, I propose to use mm100 as the class' base units, and
double as the type for the stored value. That allows to represent any whole
number of mm100s up to 2^53 (i.e., up to 90 071 992 547 meters); it will also
allow to unambiguously represent any reasonable whole value in EMUs (greater
than 20 million meters).

The task would be first to create such a class, and start using it; then
gradually make more and more code use it, passing it around, and avoid
conversions except in places of input and output.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201110/36529711/attachment.htm>


More information about the Libreoffice-bugs mailing list