[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