On 12/26/22 20:01, Gero Peterhoff via Boost wrote:
Am 26.12.22 um 14:18 schrieb John Maddock via Boost:
I guess in principle, since there is no real guarantee that there are any such types, these would all be BOOST_HAS_ macros.
I think, the idea was to have the least amount of definitions on a fully conforming compiler. I'm not sure if the number of defined macros measurably affect compilation performance, but having a naming scheme that results in an ever growing list of defined macros doesn't sound too good.
However, I have two questions:
1) Which Boost library need this? Generally speaking Config is there for configuring Boost libraries, and as mentioned early in this topic, wasn't originally intended for end-user use.
2) How would we implement this? Short of clairvoyance, I don't see how this is possible in the general case for all the integer and floating point widths.
Also, is this not already largely solved in the integer case by <cstdint> ?
In the floating point case, the only major questions, are:
* Do we have __float128 as an extension: this is already covered.
* Is long double a __float128: that can easily determined by querying LDBL_MANT_DIG
What am I missing?
John.
Hi John, Basically, I'm all about consistency.
integer Apparently not all platforms have u/int64_t, hence BOOST_NO_INT64_T. Something similar could (I'm not sure) also apply to u/int8_t, eg 16-bit DSPs with CHAR_BIT==16 -> BOOST_NO_INT8_T. I don't know of any platforms for u/int16/32_t that don't support it, but you never know ... maybe you know which ones.
float In
there is BOOST_CSTDFLOAT_HAS_FLOATxxx_NATIVE_TYPE, but then they become undefined. I use BOOST_CSTDFLOAT_FLOATxxx_NATIVE_TYPE. ugly. So we need BOOST_NO_FLOATxxx_T.
You are mixing up macros defined by different libraries, Boost.Config and Boost.Math. You may be looking at Boost as a monolithic thing, but it really isn't, and the different macro names are intentional to avoid conflicts between libraries. You could argue to move some of the Boost.Math definitions to Boost.Config, though.
I'll update my config_integer.hpp + config_float.hpp and then send them to you.
In addition, then stand for float: boost::float128_t + boost::float128_type + boost::math::cstdfloat::detail::float_internal128_t are available integer: only boost::(u)int128_type, but no boost::(u)int128_t It would make sense to consolidate this so that there is only boost::xxx128_t and no boost::xxx128_type to eliminate the redundancies and stick to the standard naming scheme.
I believe, the reason that the types have "_type" suffix is to avoid using the "_t" suffix to keep it available for standard types. Not that I'd be a fan of an int128_t built-in type name, but we have precedents.