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 Is there an issue already open? If not can you open one (and a PR if
Am 07.09.20 um 00:00 schrieb Gero Peterhoff via Boost: possible)?
- 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 This is a feature request, isn't it? So no char32/16_t detection exists yet? Just making sure as you wrote "do not work reliably" - 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 Both of those are perfectly expected and a result of your first point. At least if "do not work" means "are not defined when they should be". Is that what you meant? 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 The types are spelled "float128" and "char32_t". Hence the macros are spelled "HAS_FLOAT128" and "HAS_CHAR32_T". It is always "BOOST_HAS_<type name>". Or did you see something different? - 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. Careful here. The C++ std went with a "_t" suffix for typedefs. So I'd keep that. Can you clarify what you would rename exactly and why? Adding an alias for boost::float128_t to the existing type makes sense IMO.