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) #if __has_include(<quadmath.h>) # define BOOST_HAS_FLOAT128 #endif #endif #endif 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". HTH, John.
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 Gero
_______________________________________________ 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