Unfortunately iwyu gets quite confused by the weird cyclic dependencies
between various foo.h/foo.hxx and cppumaker generated headers, so it's
not obvious if any improvement here is realistic...
Change-Id: I0bc66f98b146712e28cabc18d56c11c08418c721
And remove the tools/fract.hxx include.
grep -l -r fract.hxx workdir/Dep/*Object* |wc -l
before: 4569
after: 1851
Shrinks some libraries, example from --enable-dbgutil Fedora gcc 4.8.3:
libvcllo.so by 473k (0.35%)
libswlo.so by ~1Mb (sadly that is just 0.2%)
Change-Id: I09bd025d551a5d2c5528b938a68c6aa5f8f114a0
and make the two categories of constants non-overlapping, we
really don't need to risk confusion in order to save 6 bits in
a data structure like this.
Change-Id: I2251195d8e45ed04e2a89e47ae9c3e52cf0475c0
This reverts commit 05050cdb23de586870bf479a9df5ced06828d498,
not all places that use e.g. OStringToOUString to convert potential UTF-8
are guaranteed to fulfil the prerequisites necessary to use fromUtf8 (and
some places like e.g. in codemaker are happy with the best-effort effect
of OStringToOUString's OSTRING_TO_OUSTRING_CVTFLAGS).
they are largely unnecessary these days, since our OUString infrastructure
gained optimised handling for static char constants.
Change-Id: I07f73484f82d0582252cb4324d4107c998432c37
* 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>
Put the TOOLS PolyPolygon class in the tools namespace. Avoids clash with the Windows
PolyPolygon typedef.
Change-Id: I811ecbb3d55ba4ce66e4555a8586f60fcd57fb66
Also remove the tools/solar.h included from tools/debug.hxx. The include of solar.h
header was necessary in some cases because of a macro or a typedef that was needed.
Change-Id: Ia6e15d5c2571c58c9e9138b0d0a7f08ae88053c9
Reviewed-on: https://gerrit.libreoffice.org/11075
Reviewed-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Tested-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
most of length in vcl are calculated in 'long'
but array of X position tend to be in sal_Int32.
As a prep work to be able to support 'double'
as the base type of Device Coordinate, harmonize
the use of 'long' for non-float coordinate.
Change-Id: I7cb33301ff6a5e2c62247b36a4e07e168a58a323
Find "missing headers," where a function is declared directly in the
.cxx (as extern) and not defined, and should arguably instead be declared
in an include file.
Change-Id: I6d83ee432b2ab0cd050aec2b27c3658d32ac02a2
Apparently some time before inital CVS import a global
search-and-replace went horribly wrong and added spurious namespace
prefixes everywhere.
Change-Id: I4009bc3ab4b1d4c80412f75ad0e4628a382f99f0
