On 14/12/2020 08:46, Rene Engelhard wrote:
Am 14.12.20 um 07:57 schrieb Mike Kaganski:
On 11.12.2020 23:41, Dante Doménech wrote:
We have our own isnan, isinf, isfinite, ... and some of them with
quite strange code.
Why is the default c++ standard library isn't good enough?
See also https://bugs.documentfoundation.org/show_bug.cgi?id=130975
and https://bugs.documentfoundation.org/show_bug.cgi?id=130976.
I wonder why these commits didn't change sal to just call the library
function?
Stephan only said that the function must not go because it's part of the
interface, but that doesn't say one can't just make it a function
calling the library function?
That should be ABI compatible, shouldn't it?
Taking <https://bugs.documentfoundation.org/show_bug.cgi?id=130975>
"Drop rtl::math::isNan in favor of std::isnan" as an example:
LO-internal code can and should call std::isnan directly. But
include/rtl/math.hxx must continue to provide an rtl::math::isNan that
works with pre-C99, pre-C++11 compilers, so that inline function cannot
call std::isnan internally. (And as no internal code should call it,
why bother with adding, say, a LIBO_INTERNAL_ONLY branch to its
implementation that would call std::isnan. What we could do though is
mark rtl::math::isNan as deprecated, at least for the LIBO_INTERNAL_ONLY
case.)
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
