From: John Maddock (jz.maddock_at_[hidden])
Date: 2020-09-07 09:43:37
On 06/09/2020 23:00, Gero Peterhoff via Boost wrote:
> Hello Developer,
> I noticed that some type detection macros and boost::float128_type or numeric_limits do not work reliably:
> - BOOST_HAS_FLOAT128 with clang and icc do not work, gcc is ok
This is deliberate - now I admit I need to recheck with the latest clang
and Intel compiler versions - but last time I did check there were
enough features missing to warrant not setting the macro.
In fact clang will set that macro if <quadmath.h> is present, the actual
detection logic is:
#if (defined(linux) || defined(__linux) || defined(__linux__) ||
defined(__GNU__) || defined(__GLIBC__)) && !defined(_CRAYC)
#if (__clang_major__ >= 4) && defined(__has_include)
#Â define BOOST_HAS_FLOAT128
Note that by default, quadmath.h is not present in clang's include path
which makes __float128 support next to useless.
> - BOOST_HAS_CHAR32/16_T, BOOST_NO_CHAR32/16_T are not defined, but either BOOST_HAS_TYPE or BOOST_NO_TYPE should be defined; see later
> - with clang there is no boost::float128_type and an error when including boost/multiprecision/float128.hpp (quadmath.h)
Correct, see above, please fix your include path to find quadmath.h
> - with clang and icc the numeric_limits<float128_t> are not available (gcc ok)
> see https://godbolt.org/z/95PfTG
> In general it would make sense:
> - convert the detection macros to a uniform naming scheme:
> always BOOST_HAS_TYPE_T (with _T at the end) or BOOST_HAS_TYPE (without _T), but not mixed/both
> - in multiprecision and math:
No, you're mixing two different things, we always use BOOST_HAS_<name>,
and the names are either "float128" or "char16_t" etc, there is no
"float128_t" or "char16".
> 1) float: renaming typenames to eg floatBits_mbt (m: multiprecision, b: binary); floatBits_mdt (d: decimal)
> 2) integer: renaming typenames to e.g. u/intBits_mt; u/intBits_mct (c: checked)
> 3) based on this, renaming boost::float/int128_type to boost::float/int128_t
> so that it is always clear and there is no confusion.
> You can do that for all types, e.g. some DSP/microcontrollers do not support u/int8/64_t etc. I did that quickly for gcc (has_type.hpp) - of course that has to be in the corresponding boost/config/compiler/* and platform/* headers are implemented.
> Building on this, feature test macros can then be made available (features.hpp).
> Can you please implement the io-operators and string-conversions for u/int128 (in e.g. boost/math/cstdint/cstdint_iostream.hpp)?
> thx and regards
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk