On Fri, Dec 23, 2022 at 12:33 PM John Maddock via Boost wrote:

...

...

Is someone willing to explain to me why we have Predef and Config? There are probably a couple of people who can explain. I might even be one of them. And this would be easier to explain if the Config documentation was better. Specifically in the area of stating its goal, what it's meant to do, its domain of operation, its reason for existence. Perhaps we are supposed to know everything just from its name? Do we dare ask for someone to volunteer such information be communicated in the documentation? Or do we all just know?

Perhaps we do (or not!)

I see the two libraries as orthogonal: Config answers the question "does the current compiler/platform/std lib have feature X?" without the user needing to know anything about what the current compiler/platform/stdlib actually is. Where as predef provides a unified way to figure out what the current compiler/platform etc really is, and what version it is. This is obviously a brilliant fallback for situations when Config doesn't have a necessary feature test macro ;)

That, indeed, makes some sense. Predef aims to answer the who of it all. While Config aims to answer the what of it all. Did I already know this? Only I will ever know :-)

I should also state, that Config was never really intended to be a library for the end user (though I'm aware that some do use it), indeed we rather discouraged end-user usage. Rather it was a bunch of shared configuration code, dating back to the heady days when there were only a handful of Boost libraries and everyone round here knew everything that was going on in each of them! Arguably it should be long dead by now, though I have to admit that I'm rather pleased it still mostly just plain works, and even the C++20 feature test macros are rather tedious to use in comparison (even though I was rather hoping they would eventually replace it).

That seems to be an eternal story for Boost. People wish for each new version of C++ to replace something in Boost. And each new C++ edition seems to fall short of that wish. Is that a good thing? As it keeps our work relevant. Or is it a bad thing? That we are failing to impact the standard per the ostensibly noble BoostORG goals. Should we reconsider the goals of the Boost C++ Libraries?

So they could be merged, or not. I'm not sure how much it matters either way ;)

Should it matter? Is it important to combine the who, what, where, when of C++ functionality into one library? Hm, not even the standard tries to do that. Should Boost do that? Should a single Boost library do that? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

On 12/23/22 12:00 PM, Joaquín M López Muñoz via Boost wrote:

I have to say Boost.Config is a wonderful piece of engineering, and don’t see it dying any time soon.

+1 Config is indispensable to anyone writing a portable library

Joaquín M López Muñoz

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

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? thx Gero

Am 26.12.22 um 14:18 schrieb John Maddock via Boost:

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.

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. 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 would also like to provide macros/traits that check whether a type is natively available on the platform, eg BOOST_NO_NATIVE_xxx_T/is_native. This is especially useful with the float types from std (C++23 stdfloat). Eg I have a complicated algorithm template Type foo(const Type arg); If I call this with Type=std::(b)float16_t and these are not native, the emulation/conversion to/from float is constantly called within foo. This is slow and inaccurate. With the checks I can then implement (pseudo-code): template Type foo(const Type arg) { if (Type == std::(b)float16_t && !is_native_v<Type>) using type = float; else using type = Type; return Type(detail::foo_impl(type(arg)); } or foo specialize. There also seems to be an issue with . a) promote_arg returns the correct type b) for Type=boost::float16_t or std::(b)float16_t deliver promote_args_2 -> float promote_args -> float Shouldn't that be Type? See eg : template inline typename tools::promote_args<T>::type cbrt(T z, const Policy& pol) { using result_type = typename tools::promote_args<T>::type; using value_type = typename policies::evaluation::type; return static_cast(detail::cbrt_imp(value_type(z), pol)); } template <typename T> inline typename tools::promote_args<T>::type cbrt(T z) { return cbrt(z, policies::policy<>()); } thx & regards Gero

Hi John, here are my results. However, I found that it makes no sense to implement the native checks as a macro. 1) config_more.hpp: implements missing macros -> that would come anyway 2) config_float.hpp + config_integer.hpp: the std types are preferred for the min/max types in boost::platform. 3) is_native.hpp (for boost/type_traits/) As I said, it would make sense if 1+2 were implemented directly in config. thx Gero PS: It would have been nicer to use BOOST_HAS/IS/ETC_XXX instead of BOOST_NO_XXX. So you have to check for !BOOST_NO_XXX to get true. This is confusing and error-prone.

On Fri, Dec 23, 2022 at 9:29 AM Vinnie Falco via Boost wrote:

On Fri, Dec 23, 2022 at 3:14 AM Hans Dembinski via Boost wrote:

...

Is someone willing to explain to me why we have Predef and Config?

I only have one data point to contribute: I use Boost.Config, but I do not use Boost.Predef. Correlation does not imply causation.

There have been a handful of instances, I'm aware of, of external, non-Boost, users of *only* Predef. There's even a conference talk where the presenter recommends people use Predef. Does that point towards keeping them separate? Does it point to anything at all? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net