Re: type detection macros + multiprecision + io

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2020-09-07 07:44:29

Am 07.09.20 um 00:00 schrieb Gero Peterhoff via Boost:
> 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 
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<float128_t> 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.