Re: type detection macros + multiprecision + io

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)
#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