Re: [boost] Why do Predef and Config exist?

On 26/12/2022 12:57, Gero Peterhoff via Boost wrote:

Am 25.12.22 um 09:45 schrieb Mathias Gaunard:

...

On Sat, 24 Dec 2022, 18:38 Gero Peterhoff via Boost, mailto:boost@lists.boost.org> wrote:

    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

Boost.Config uses NO for lack of standard features and HAS for extensions.

OK. But that's what I mean: the user doesn't care whether a type is only available via an extension or not. He just wants to check whether this type is available -> uniform named macros. Would it be legitimate to introduce BOOST_NO_FLOAT128_T + BOOST_NO_INT128_T and other (like BOOST_NO_INT64_T) to do this?

I guess in principle, since there is no real guarantee that there are any such types, these would all be BOOST_HAS_ macros. 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.* * * *