Why do Predef and Config exist?
Hi all, since there were concerns that the email list is so quiet, here is some noise. Is someone willing to explain to me why we have Predef and Config? It looks like these two libraries have a strong overlap in scope. Shouldn’t they be merged? Best regards, Hans
On Fri, Dec 23, 2022 at 5:14 AM Hans Dembinski via Boost <boost@lists.boost.org> wrote:
Hi all,
since there were concerns that the email list is so quiet, here is some noise.
Since, I guess, we are looking to fluff up this list. I guess I can add semi-coherent words ;-)
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? So let me look at Predef, it says: == This library defines a set of compiler, architecture, operating system, library, and other version numbers from the information it can gather of C, C++, Objective C, and Objective C++ predefined macros or those defined in generally available headers. == Look at that. Seems clear to me what Predef does. I know I'm biased. Since I wrote that sentence. Should one write something else to make it clearer? What is missing from the description and documentation of Predef? Let's check.. reading the following sentence. == The idea for this library grew out of a proposal to extend the Boost Config library to provide more, and consistent, information than the feature definitions it supports. ==
It looks like these two libraries have a strong overlap in scope.
Hm, interesting. It does appear there is some overlap. It says so right there as "extend the Boost Config library". But can't really say for sure as the scope of Config is technically undefined. I clearly had some idea of what the scope of Config was at the time I wrote the above. There is one clear aspect though: Predef provides "more, and consistent, information". Yet, there is one clue to follow. That sentence says "feature definitions it [Config] supports". Clearly, at minimum, Config provides "feature definitions". Since Boost is "Boost C++ Libraries", we can only assume it's C++ features it's referring to. And if we check the first sentence, i.e. the goal of Predef, it doesn't mention C++ features. Hence, there appears to be a clear dividing line in what Predef covers. But let me ask you.. What do you think is the overlap? What do you think makes it strong?
Shouldn’t they be merged?
What an interesting question. It brings up some other questions to mind. So let me rephrase your question(s).. Why should they be merged? What is gained by merging? What is lost by merging? Are there alternatives to merging them? HTH -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
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 ;) 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). So they could be merged, or not. I'm not sure how much it matters either way ;) John.
On Fri, Dec 23, 2022 at 12:33 PM John Maddock via Boost <boost@lists.boost.org> 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 Fri, Dec 23, 2022 at 12:33 PM John Maddock via Boost <boost@lists.boost.org> wrote:
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 […]
I have to say Boost.Config is a wonderful piece of engineering, and don’t see it dying any time soon. Joaquín M López Muñoz
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
On Fri, Dec 23, 2022 at 2:47 PM René Ferdinand Rivera Morell wrote:
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?
Boost.Boost : One library, no dependencies, zero cycles.
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
On Sat, 24 Dec 2022, 18:38 Gero Peterhoff via Boost, <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.
Am 25.12.22 um 09:45 schrieb Mathias Gaunard:
On Sat, 24 Dec 2022, 18:38 Gero Peterhoff via Boost, <boost@lists.boost.org <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
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@lists.boost.org <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.* * * *
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, <boost@lists.boost.org <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 <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. 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 <std::floating_point Type> 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 <std::floating_point Type> 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 <boost/math/tools/promotion.hpp>. a) promote_arg returns the correct type b) for Type=boost::float16_t or std::(b)float16_t deliver promote_args_2<Type, Type> -> float promote_args<Type, Type...> -> float Shouldn't that be Type? See eg <boost/math/special_functions/cbrt.hpp>: template <typename T, typename Policy> 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<result_type, Policy>::type; return static_cast<result_type>(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
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.
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 3:14 AM Hans Dembinski via Boost <boost@lists.boost.org> 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. Regards
On Fri, Dec 23, 2022 at 9:29 AM Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Fri, Dec 23, 2022 at 3:14 AM Hans Dembinski via Boost <boost@lists.boost.org> 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
participants (10)
-
Andrey Semashev -
Gero Peterhoff -
Glen Fernandes -
Hans Dembinski -
Joaquín M López Muñoz -
John Maddock -
Mathias Gaunard -
René Ferdinand Rivera Morell -
Robert Ramey -
Vinnie Falco