Boost logo

Boost :

From: John Maddock (jz.maddock_at_[hidden])
Date: 2022-12-26 13:18:24


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,
>> <boost_at_[hidden] <mailto:boost_at_[hidden]>> 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.*
*

*
*


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk