- Boost - lists.preview.boost.org

Re: [boost] Reducing dependency on Boost.Regex
by Boris Kolpackov 13 Mar '23

13 Mar '23

John Maddock via Boost <boost(a)lists.boost.org> writes: > Can I just point out that regex is now header only, and thus the dependency > is only there if it's actually used, likewise ICU is not required to be > present at build time, but only if boost/regex/icu.hpp is actually used. This implicit "if you don't include the header then you don't need to link the dependency" approach doesn't scale well to cases where Boost is split into individual packages which are managed by a package manager. When the package manager undertakes to provide a Boost library, it should come with all the dependencies that could be needed for any usage scenario, unless certain features are explicitly not enabled (which is essentially what we have done -- not enabled regex by default in a bunch of libraries; I suppose we could have instead not enabled ICU in regex by default).

1 0

Re: [boost] quadmath as distinct library?
by John Maddock 13 Mar '23

13 Mar '23

On 13/03/2023 02:43, Gero Peterhoff via Boost wrote: > Hello, > * problem description > In boost::math::cstdfloat AND boost::multiprecision::float128 > identical functions for __float128 (quadmath) are provided. > > This is unnecessary overhead. I think it would make sense to "pull > out" the quadmath library as a distinct library. I did this once > canonically, but it doesn't work yet because > boost::math::cstdfloat/boost::multiprecision::float128 have to be > adapted for this. This is a prototype where there is still a lot of > work to be done. But the beginning is done. If you mean https://github.com/boostorg/multiprecision/blob/develop/include/boost/multi… then it's a trivially small header, and spinning stuff out into a separate library has a significant maintenance overhead. > > Would it also make sense to "pull out" quaternion and octonion as > distinct libraries? Historically these were separate libraries, and were unmaintained. Moving them under the Boost.Math "umbrella" means that they do at least get minimal maintenance now. Again, splitting stuff out has a non-zero overhead. John.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by John Maddock 13 Mar '23

13 Mar '23

On 13/03/2023 12:00, Boris Kolpackov via Boost wrote: > A quick note on our experience reducing dependency on Boost.Regex > (and thus ICU) in build2 packages for Boost 1.81.0. Can I just point out that regex is now header only, and thus the dependency is only there if it's actually used, likewise ICU is not required to be present at build time, but only if boost/regex/icu.hpp is actually used. [technically, I haven't yet removed the old C++98 code which does have a dependency on ICU, but it will be going very soon]. John.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Boris Kolpackov 13 Mar '23

13 Mar '23

Andrey Semashev via Boost <boost(a)lists.boost.org> writes: > Boost.Log can be configured to use std::regex or Boost.Xpressive as an > alternative to Boost.Regex. > > https://www.boost.org/doc/libs/1_81_0/libs/log/doc/html/log/installation/co… > > Boost.Regex is the default because it provides the best performance. I'm > not planning to change this. I don't think there would be strong motivation to change this in Log since it's a leaf library (i.e., no other Boost library depends on it). But we can make this configurable in our package if/when there is interest.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Andrey Semashev 13 Mar '23

13 Mar '23

On 3/13/23 15:00, Boris Kolpackov via Boost wrote: > A quick note on our experience reducing dependency on Boost.Regex > (and thus ICU) in build2 packages for Boost 1.81.0. Now only the > following (leaf) libraries unconditionally depend on Boost.Regex: > > * Boost.Convert > * Boost.DLL > * Boost.Log Boost.Log can be configured to use std::regex or Boost.Xpressive as an alternative to Boost.Regex. https://www.boost.org/doc/libs/1_81_0/libs/log/doc/html/log/installation/co… Boost.Regex is the default because it provides the best performance. I'm not planning to change this.

1 0

Reducing dependency on Boost.Regex
by Boris Kolpackov 13 Mar '23

13 Mar '23

A quick note on our experience reducing dependency on Boost.Regex (and thus ICU) in build2 packages for Boost 1.81.0. Now only the following (leaf) libraries unconditionally depend on Boost.Regex: * Boost.Convert * Boost.DLL * Boost.Log While the following libraries now have an optional (direct or indirect) dependency (follow the link for details on what functionality is now optional and how to enable it): * Boost.Algorithm[1] * Boost.Asio[2] * Boost.Graph[3] * Boost.Iostreams[4] * Boost.Range[5] * Boost.Spirit[6] To achieve this we had to make the following two changes: 1. Make functionality that requires regex optional. This change was made in all the above-mentioned libraries. In all the cases except Boost.Spirit and arguably Boost.Graph, the regex-based functionality was fairly marginal and making it optional feels like a reasonable trade off. 2. Split Boost.Spirit into three logical "components", all optional: classic, v2, and x3. The rationale here is that only the classic component can be reasonably easily made to work without regex. And classic without regex is what's required by Boost.Serialization (we had to deal with Boost.Serialization because it is a dependency of the majority of Boost libraries). We only had to patch Boost.Graph and are working[7] to upstream our changes. Overall, while this required some effort, it's definitely achievable given appropriate tools (mainly support for dependency configuration in the package manager). [1] https://github.com/build2-packaging/boost/blob/master/downstream/libs/algor… [2] https://github.com/build2-packaging/boost/blob/master/downstream/libs/asio/… [3] https://github.com/build2-packaging/boost/blob/master/downstream/libs/graph… [4] https://github.com/build2-packaging/boost/blob/master/downstream/libs/iostr… [5] https://github.com/build2-packaging/boost/blob/master/downstream/libs/range… [6] https://github.com/build2-packaging/boost/blob/master/downstream/libs/spiri… [7] https://github.com/boostorg/graph/issues/326

1 0

Re: [boost] quadmath as distinct library?
by Dominique Devienne 13 Mar '23

13 Mar '23

On Mon, Mar 13, 2023 at 3:48 AM Gero Peterhoff via Boost < boost(a)lists.boost.org> wrote: > Would it also make sense to "pull out" quaternion and octonion as distinct > libraries? There's already a [Boost.QVM][1] library for Quaternions. Are you aware of it? [1]: https://www.boost.org/doc/libs/1_81_0/libs/qvm/doc/html/index.html

1 0

quadmath as distinct library?
by Gero Peterhoff 13 Mar '23

13 Mar '23

Hello, * problem description In boost::math::cstdfloat AND boost::multiprecision::float128 identical functions for __float128 (quadmath) are provided. This is unnecessary overhead. I think it would make sense to "pull out" the quadmath library as a distinct library. I did this once canonically, but it doesn't work yet because boost::math::cstdfloat/boost::multiprecision::float128 have to be adapted for this. This is a prototype where there is still a lot of work to be done. But the beginning is done. Would it also make sense to "pull out" quaternion and octonion as distinct libraries? thx + regards Gero

1 0

Re: [boost] improve <boost/math/constants.hpp>
by John Maddock 11 Mar '23

11 Mar '23

On 10/03/2023 21:12, Gero Peterhoff via Boost wrote: > Hello, > * Problem description > The constants do not work with the C++23 FP types. We will make sure that they will - once a working implementation is *released*. > > * general hint > To prevent (more) warnings it is useful to introduce this macro: > #if defined(__STDCPP_FLOAT128_T__) From past experience, __STDCPP_FLOAT128_T__ is a deeply unreliable indicator. > * question > In constants the namespaces float/double/long_double_constant+detail > are created type dependent (in case the value constexpr can be > requested). If the value cannot be requested constexpr the conversion > is finally done by boost::lexical_cast. > But the implementation is very complex. I have a better one - but I > may have missed things. > If so - which would they be? Off the top of my head I see two main correctness issues: * Your code introduces *double rounding* for float/double (and maybe long double) types, as a result the constants for these types will no longer guarantee last digit accuracy. This is a deal breaker for me. * For multiprecision types with more digits than we can reasonably store in a string your constants will have insufficient accuracy (cached runtime calculation is needed in this case). It's also lacking some "nice to have" features, for example, you have all UDT types going the lexical_cast route, but if the type can be constructed from a builtin type with sufficient precision, then the code is more efficient and constexpr that way. For example with boost::multiprecision::float128. John. > > * My solution (BOOST_MAKE_MATH_CONSTANT) > see constants_more.hpp, advantages: > - works with all FP types > - compatible to the existing implementation CONSTANT<Type>() > - is clear/understandable (comments) > - may need only one additional namespace static_constants (and not 4) > - provides the constants additionally as CONSTANT_v (constexpr) or > static_constants::CONSTANT_v (not constexpr) (if possible) > > What is your opinion? Are there still errors in it? > > It would be even nicer if boost::lexical_cast and/or > boost::math::tools::convert_from_string were constexpr. This would > further simplify the implementation. > > thx + regards > Gero > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] improve <boost/math/constants.hpp>
by Matt Borland 10 Mar '23

10 Mar '23

> On Mar 10, 2023, at 1:11 PM, Gero Peterhoff via Boost <boost(a)lists.boost.org> wrote: > > Hello, > * Problem description > The constants do not work with the C++23 FP types. > > * general hint > To prevent (more) warnings it is useful to introduce this macro: > #if defined(__STDCPP_FLOAT128_T__) > #define BOOST_FLOATMAX_SUFFIX F128 > #elif defined(BOOST_CSTDFLOAT_FLOAT128_NATIVE_TYPE) > #define BOOST_FLOATMAX_SUFFIX Q > #else > #define BOOST_FLOATMAX_SUFFIX L > #endif > > * question > In constants the namespaces float/double/long_double_constant+detail are created type dependent (in case the value constexpr can be requested). If the value cannot be requested constexpr the conversion is finally done by boost::lexical_cast. > But the implementation is very complex. I have a better one - but I may have missed things. > If so - which would they be? > > * My solution (BOOST_MAKE_MATH_CONSTANT) > see constants_more.hpp, advantages: > - works with all FP types > - compatible to the existing implementation CONSTANT<Type>() > - is clear/understandable (comments) > - may need only one additional namespace static_constants (and not 4) > - provides the constants additionally as CONSTANT_v (constexpr) or static_constants::CONSTANT_v (not constexpr) (if possible) > > What is your opinion? Are there still errors in it? > > It would be even nicer if boost::lexical_cast and/or boost::math::tools::convert_from_string were constexpr. This would further simplify the implementation. > > thx + regards > Gero > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > <config_more.hpp><cstdfloat_types_more.hpp><constants_more.hpp><OpenPGP_signature.sig> Gero, As John and I have said before we are aware that C++23 fixed width floating point types will break Boost.Math. We have a type promotion system for built-in types that will fail because we do not have any code paths for those types yet. GCC 13 will be released in the next month or two and then we can throughly test and fix these issues. For the constants lexical_cast is almost never used. If we are operating with arbitrary precision arithmetic typically the types have string/char* constructors, (e.g. GMP, Boost.Multiprecision, etc.) so lexical_cast is not needed. You would also likely end up having to calculate the constant at runtime which we support (see boost/math/constants/calculate_constants.hpp). If you would like you can open a PR with your changes on our GitHub. Without the tests being run it is hard to tell if there are errors outside of the obvious. Matt

2 1