summaryrefslogtreecommitdiff
path: root/include/tools/fract.hxx
AgeCommit message (Collapse)Author
2022-10-27tdf#123419 optimise ImplMakeFractionNoel Grandin
which is very hot here. Push it down into Fraction, where we can skip the construction of boost::rational intermediate values Change-Id: I7e5f18456a252a159d3a50e9297168e5ba9e1588 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141894 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-12include OutputDevice MapMode in SalLayoutGlyphsCache key (tdf#148400)Luboš Luňák
The mapmode also affects the layout of the glyphs. Change-Id: I9492bc4d3d9e991ef8ab5dc30ce424e44cbc79f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132822 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-07-06Explicitly call an operator to avoid a bogus IntelliSense warningMike Kaganski
More than one conversion function from "const Fraction" to "sal_Int32" applies: function "Fraction::operator sal_Int32() const" (declared at line 54) function "Fraction::operator tools::Long() const" (declared at line 56)" Change-Id: Id6f72c386d395509d3853ffc8e1a7852cca45e6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118429 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-14loplugin:unusedmethodsNoel Grandin
Change-Id: I9c1c6f27e35a66d8e3623c3ebb1618dceda60e24 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113988 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-02vcl: move Fraction reading/writing to GenericTypeSerializerTomaž Vajngerl
Change-Id: Iccacaa7fd9cffe1d99f76def854c2150bb4d94f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113499 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-11-12Revert "remove Fraction::operator tools::Long()"Noel Grandin
This reverts commit 48b667a7e7d25f835f95df89162a7849d6972531. Reason for revert: some discussion required Change-Id: Ia0990d280837fb68b7ddc9f472ec78b1467b4311 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105540 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-12remove Fraction::operator tools::Long()Noel
which was added in commit 331e2e5ed3bf4e0b2c1fab3b7bca836170317827 Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Thu Sep 14 08:49:52 2017 +0200 long->sal_Int32 in Fraction presumably to make the change impact less code. Instead, update the call sites to reflect the actual bitwidth of the data we will be receiving. Change-Id: If2a678b1cf534f39cb8cb249757462be53658309 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105607 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11make tools::Long 64-bit on Windows platformNoel Grandin
This is only for the 64-bit windows platform. I don't see the point in messing with the 32-bit platforms, they are (a) become more and more rare (b) unlikely to even have enough available process memory to load extremely large calc spreadsheets The primary problem we are addressing here is bringing Windows-64bit up to same capability as Linux-64bit when it comes to handling very large spreadsheets, which is caused by things like tools::Rectangle using "long", which means that all the work done to make Libreoffice on 64-bit Linux capable of loading large spreadsheets is useless on Windows, where long is 32-bit. The operator<< for tools::Rectangle needs to be inside the tools namespace because of an interaction with the cppunit printing template stuff that I don't understand. SalPoint changed to use sal_Int32, since it needs to be the same definition as the Windows POINT structure. Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-19add tools::Long typedef and use it in toolsNoel
first step to switching long to a 64-bit type on 64-bit windows Change-Id: I640d807426dfe713c7a8984ef560575f8288dbeb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104516 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-03tdf#42949 Fix IWYU warnings in include/[t-x]*/*hxxGabor Kelemen
Recheck after 7-0 branchoff Also drop the now unused file include/vcl/field.hxx Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I9e54c82f50d1e02a0f99858939cac999fc66f7de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99261 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-06-25tdf#94677 Calc is slow opening large CSV, improve tools::FractionNoel Grandin
Flatten the tools::Fraction class. Shaves 1s off a load time of 49s Change-Id: I7cbee9892831a1e47704a283351fa97eda262343 Reviewed-on: https://gerrit.libreoffice.org/74639 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-26tools: print some FractionsMichael Stahl
Change-Id: Idc4668cba7412d0b4a3e486a8629c7f95a701091
2017-10-16-Werror,-Wtautological-constant-compare (Clang 6)Stephan Bergmann
...making Fraction::HasOverflowValue() always return false on all platforms, regardless of size of long, since 331e2e5ed3bf4e0b2c1fab3b7bca836170317827 "long->sal_Int32 in Fraction" changed Fraction::Impl::value from boost::rational<sal_Int64> to boost::rational<sal_Int32>, and changed the limits to compare with in Fraction::HasOverflowValue from long to sal_Int32. Change-Id: I226ca240d6092ac803a1f65a363b1384903da17a
2017-09-27check for NaN in FractionNoel Grandin
which can result from division by zero in earlier code, rather assert explicitly than suffer from weird very large sal_Int64 values (which is what NaN converts to, if we let it do the implicit conversion) Change-Id: Id059b84906bbc90a4fa51489ca96dc0267bb9342 Reviewed-on: https://gerrit.libreoffice.org/42798 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-09-15long->sal_Int32 in FractionNoel Grandin
because long is 32bits on Windows and 64bits on Linux. Reasoning: (a) all the users of Fraction used to be 32bit in the past (b) this makes the Linux code behave the same as the Windows code (c) changing it to 64bits would be dangerous because then call sites could see silent truncation. Change-Id: I2a36200623a3cf2e7d62ccad030a20614e1798fb Reviewed-on: https://gerrit.libreoffice.org/42200 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-09-13Fraction: make conversion operators and constructor explicitNoel Grandin
and simplify some of the calculations that needed to be changed. Which resulted in one unit test needing to change by one pixel, let's hope not an indication of a real problem. Change-Id: Ie56434f35f4e58d21ee6f671392e93dc7542fca3 Reviewed-on: https://gerrit.libreoffice.org/42240 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-09-05drop default param from Fraction::FractionNoel Grandin
because if I make call-sites use the default, I get warnings about ambiguous functional conversions Change-Id: Ifd452c946832d0f9d62a10a46d90fe1ea3e79945
2016-08-29cid#1371160 Missing move assignment operatorNoel Grandin
Change-Id: Ifcddd08cd1ec6bfb7679ee0433524c4bd68803dd
2016-07-13loplugin:constparams in toolsNoel Grandin
Change-Id: Iea05efbb90a0a95fefd18ae9673095a31422f06c Reviewed-on: https://gerrit.libreoffice.org/27137 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2015-12-10Fix order of SAL_WARN_UNUSED and DLLPUBLIC for clang-clStephan Bergmann
...which, somewhat arbitrarily, expects GNU extension __attribute__((...)) to come before MSVC extension __declspec(...) with MaybeParseGNUAttributes(attrs); MaybeParseMicrosoftDeclSpecs(attrs); in Parser::ParseClassSpecifier (lib/Parse/ParseDeclCXX.cpp). Change-Id: I5936558c8fc08b278575b6c678cde6eccd4647fb
2015-11-17use unique_ptr for pImpl in tools/Noel Grandin
Change-Id: I7ac7eca32a67524f6c87696c16b16128e6d8518b
2014-11-17Apply pimpl to Fraction.Kohei Yoshida
Change-Id: I60eb597a6374b807b2264af6d5841a42e9b1c0f3
2014-11-17Make these methods non-inline.Kohei Yoshida
Change-Id: I0b24e34dec6c452659b224b45a6849dafe708c3b
2014-10-28fdo#81356: use boost::rational internally in FractionJuan Picca
Change-Id: I6f40eafee7652209395bd471e3508fe3a3d19d73 Reviewed-on: https://gerrit.libreoffice.org/12085 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
2014-10-23Fraction: Revert "fdo#81356: convert Fraction to boost::rational<long> - wip"Jan Holesovsky
This reverts commit 47a2d7642d249d70b5da0c330a73f3a0032e4bba. Conflicts: cui/source/tabpages/transfrm.cxx svx/source/svdraw/svdedtv1.cxx svx/source/svdraw/svdibrow.cxx sw/source/filter/ww1/w1filter.cxx tools/source/generic/rational.cxx Change-Id: I4849916f5f277a4afef0e279b0135c76b36b9d15
2014-10-09fdo#81356: convert Fraction to boost::rational<long> - wipJuan Picca
* Added rational util functions used by Fraction class not available in the boost::rational class. * Replaced usage of Fraction by boost::rational<long> * Removed code that relies on: 1. fraction.IsValid() -- rational only allow valid values, ie denominator() != 0 2. rational.denominator() == 0 -- always false 3. rational.denominator() < 0 -- always false but implementation detail: http://www.boost.org/doc/libs/release/libs/rational/rational.html#Internal%20representation * Simplified code that relies on: 1. rational.denominator() != 0 -- always true * BUGS EXIST because Fraction allows the creation of invalid values but boost::rational throws the exception boost::bad_rational Change-Id: I84970a4956afb3f91ac0c8f726547466319420f9 Reviewed-on: https://gerrit.libreoffice.org/11551 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
2014-03-09fdo#63154 Remove old solar.h referencesAlexandre Vicenzi
Remove some unused references in tools. Change sal_uLong to sal_uInt32 in filter and vcl. Change-Id: I92b928b980b2e7371edddfd74face10d5bec07df Reviewed-on: https://gerrit.libreoffice.org/8480 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-04convert specialised SvStream::operator>> methods to ReadXXX methodsNoel Grandin
as preparation for converting the SvStream::operator>> methods on primitive types Change-Id: I62f134bced15c687d6e0d46924f56e8d1c3d95b9 Reviewed-on: https://gerrit.libreoffice.org/7798 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2014-01-16convert SvStream::operator<< overloads to more explicit methodsNoel Grandin
This is in preparation for more conversion of SvStream::operator<< calls to use more explicit method names. This converts the subclasses that have their own convenience overloads of operator<< to use normal methods. Change-Id: I5efd5d9a24c264cb86d2471303dd5849bf91ba80
2013-11-09fdo#65108 inter-module includes <> include/toolsNorbert Thiebaud
Change-Id: I5f44f041e465230d10d562e8bd6f141848465e07
2013-10-23fixincludeguards.sh: include/{toolkit,tools}Thomas Arnhold
Change-Id: I5572c320431222be2405f8c2dc8adeafe4f3828b
2013-04-23execute move of global headersBjoern Michaelsen
see https://gerrit.libreoffice.org/#/c/3367/ and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
generated by cgit (git 2.34.1) at 2025-01-10 00:03:44 +0000