Re: Why do Predef and Config exist?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2022-12-26 17:26:01

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 <boost/math/cstdfloat/cstdfloat_types.hpp> 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.