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
- 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)
- with clang and icc the numeric_limits 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:
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
