Re: Why do Predef and Config exist?

From: Gero Peterhoff (g.peterhoff_at_[hidden])
Date: 2022-12-24 18:37:54

Hi John,
I had already addressed a similar topic and it is a good thing that this is brought up again or that other users see it that way too.
In principle, as much as possible should be consolidated and simplified (here merging config + predef) in order to be able to provide uniform interfaces/macros without the user having to dig around in the internals of boost.

Example: There is BOOST_HAS_FLOAT128+BOOST_HAS_INT128 and BOOST_NO_INT64_T.
It would make sense to provide a complete set for BOOST_HAS_FLOATxxx and BOOST_HAS_INTxxx, whereby special hardware (DSPs, microcontrollers, etc.) or compilers can then be taken into account.
However, this is made more difficult by the fact that some types of FP-types are redundant:
gcc: boost::float128_t == boost::float128_type == boost::math::cstdfloat::detail::float_internal128_t
clang/intel/other: ?
For int128 there is no boost::(u)int128_t, only boost::(u)int128_type.
This urgently needs to be consolidated:
either *only* boost::floatXXX_t/(u)intXXX_t (useful)
or *only* boost::floatXXX_type/(u)intXXX_type (doesn't make sense because it contradicts a uniform nomenclature).
Of course, the respective types of the same name from boost::multiprecision, boost and std (C++23 stdfloat) must not be mixed.

As a next step, you can check whether the types are available natively on the platform or are emulated: BOOST_HAS_NATIVE_FLOATxxx/BOOST_HAS_NATIVE_INTxxx. This is particularly useful for mathematical algorithms.

I've tried to implement this (of course it's still incomplete):
config_more.hpp: provides some missing macros
config_integer.hpp + config_float.hpp
Of course it makes sense to implement these things directly in config.

regards
Gero