- Boost - lists.preview.boost.org

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

improve <boost/math/constants.hpp>
by Gero Peterhoff 10 Mar '23

10 Mar '23

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

1 0

Re: [boost] [release] Boost 1.82.0 Beta 1 Release Candidate 1 is available
by Tom Kent 09 Mar '23

09 Mar '23

On Thu, Mar 9, 2023 at 10:24 AM Marshall Clow via Boost < boost(a)lists.boost.org> wrote: > Available at: < > https://boostorg.jfrog.io/artifactory/main/beta/1.82.0.beta1/source/> > > The SHA256 checksums are as follows: > > 495b2ae2f6970ea1e635f80222d9f6978148496cdd163e87c37cdd6de3b5ccfc > boost_1_82_0_b1_rc1.zip > 0af2a60f76abb4f411b1bd9c1a553f64454d9414990e8cc12f02f3b431e2ac45 > boost_1_82_0_b1_rc1.tar.gz > efe17bea3f0b2c11f34828f37d5777f30eb6fef57af355c6a6664b08a4339999 > boost_1_82_0_b1_rc1.7z > edf4cb9e8e5a14412b91311438478ef6ce12afe2a54714eb2f0632a454c3d8d5 > boost_1_82_0_b1_rc1.tar.bz2 > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. > > -- The Release Managers > Looks good on Windows/Visual Studio. toolset arch compile Link Execute msvc-10.0 32 X X X msvc-10.0 64 X X X msvc-11.0 32 X X X msvc-11.0 64 X X X msvc-12.0 32 X X X msvc-12.0 64 X X X msvc-14.0 32 X X X msvc-14.0 64 X X X msvc-14.1 32 X X X msvc-14.1 64 X X X msvc-14.2 32 X X X msvc-14.2 64 X X X msvc-14.3 32 X X X msvc-14.3 64 X X X Compile means that the b2 command completed without errors Link means that visual studio was able to link a sample executable to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) generated Execute means that the linked program executed without errors. Full build logs can be found here: https://gist.github.com/teeks99/ac05a822cffb8dee3390a8751a6dedeb Tom

1 0

Re: [boost] [release] Boost 1.82.0 Beta 1 Release Candidate 1 is available
by Ruben Perez 09 Mar '23

09 Mar '23

Hi all! As you may know, Boost 1.82 is the first to include Boost.MySQL, so it would be really helpful if you can have a look at it and give it a try. Thanks, Ruben.

1 0

[release] Boost 1.82.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 09 Mar '23

09 Mar '23

Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.82.0.beta1/source/> The SHA256 checksums are as follows: 495b2ae2f6970ea1e635f80222d9f6978148496cdd163e87c37cdd6de3b5ccfc boost_1_82_0_b1_rc1.zip 0af2a60f76abb4f411b1bd9c1a553f64454d9414990e8cc12f02f3b431e2ac45 boost_1_82_0_b1_rc1.tar.gz efe17bea3f0b2c11f34828f37d5777f30eb6fef57af355c6a6664b08a4339999 boost_1_82_0_b1_rc1.7z edf4cb9e8e5a14412b91311438478ef6ce12afe2a54714eb2f0632a454c3d8d5 boost_1_82_0_b1_rc1.tar.bz2 As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release Managers

1 1

Re: [boost] Moving "sub" libraries to their own repositories
by Mateusz Loskot 09 Mar '23

09 Mar '23

On Wed, 8 Mar 2023 at 21:18, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > On Mar 8, 2023, at 12:07 PM, Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > > > > We haven't been allowing this for newer libraries, but it would be nice to > > remove it from these few existing cases too. > > > > Ultimately meta/libraries.json in each library repository would have just > > one library entry. > > Boost/numeric is another such library > > % ls $BOOST/libs/numeric > conversion index.html odeint ublas > doc interval sublibs > > % find . -name sublibs > ./spirit/sublibs > ./chrono/sublibs > ./gil/sublibs TBH, I'm not clear what the existence of the sublibs file means for GIL. The sublibs content says: "sub-directories which are libraries" No idea what would those be in GIL. Extensions? The history of gil/sublibs [1] says: "sublibs file telling regression tools that subdirs contain library tests" what confuses me even more as suddenly sublibs mean two things: - directories which are libraries - directories with library tests [1] https://github.com/boostorg/gil/commit/091c86d884395571cc4a2aa4c149f9f8f184… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Release] Master branch is closed for beta
by Marshall Clow 09 Mar '23

09 Mar '23

Master is closed for all changes. See the release schedule at: https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> -- Release managers

1 0

Re: [boost] Moving "sub" libraries to their own repositories
by Vinnie Falco 09 Mar '23

09 Mar '23

On Wed, Mar 8, 2023 at 2:54 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > I suppose, they should be reviewed bottom-to-top. I think you're saying to review them in this order: 1. buffers 2. http_proto 3. http_io ? Thanks

2 1

Re: [boost] Moving "sub" libraries to their own repositories
by Andrey Semashev 08 Mar '23

08 Mar '23

On 3/9/23 00:33, Vinnie Falco via Boost wrote: > On Wed, Mar 8, 2023 at 12:55 PM Glen Fernandes <glen.fernandes(a)gmail.com> wrote: >> If they're separate libraries, they should be reviewed individually >> (and serially, since we never have reviews in parallel). I don't see >> why our review process can't handle that. > > http_proto depends on buffers > http_io depends on http_proto > > What if buffers and http_io get accepted but http_proto does not? lol... I suppose, they should be reviewed bottom-to-top.

1 0

Re: [boost] Moving "sub" libraries to their own repositories
by Vinnie Falco 08 Mar '23

08 Mar '23

On Wed, Mar 8, 2023 at 12:21 PM Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > In general I favor more fine grained smaller libraries, > than more coarse grained bigger ones. I prefer this as well and I have three libraries in development now which form a logical whole: buffers http_io http_proto These would each have to pass individual review and I suspect that our review process has not been vetted for the model where a larger work is proposed as several individual libraries. Thanks

2 2