- Boost - lists.preview.boost.org

Master is open for merges
by Marshall Clow 15 Apr '23

15 Apr '23

Master is open again, with no restrictions. Boost version numbers bumped (boost, config, more), and new release notes stubbed (website). Next milestone: June 21 Boost 1.83.0 closed for new libraries and breaking changes Release calendar: https://boost.org/development <https://boost.org/development> — Marshall

1 0

Re: [boost] [scope] scope_fail is unimplementable
by Andrzej Krzemienski 14 Apr '23

14 Apr '23

niedz., 9 kwi 2023 o 03:11 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > On 4/9/23 03:20, Andrzej Krzemienski wrote: > > > > Well, in my experience, the scope fail/success is exclusively about > > exceptions, so I will still focus on exceptions. > > Here is a small benchmark comparing the deactivation-based mechanism > > of a scope_guard with uncaught_exception-based mechanism of > scope_fail. > > The former performed like 36 times faster, as it doesn't have to > > perform the calls to the runtime. > > > > Sorry. Forgot the link. Here it is: > > https://quick-bench.com/q/0InBohGrnD5-soYT_GwvaCEaG74 > > <https://quick-bench.com/q/0InBohGrnD5-soYT_GwvaCEaG74> > > The thing with manually dismissing (or activating) the scope guard > before leaving the scope diminishes the usefulness of the scope guard. > The first and foremost reason to use a scope guard is to automate > execution of the action upon exiting the scope. If you now have to > manually ensure this at every point where you might leave the function, > what's the point of using it in the first place? > To "automate" is just one goal. A more modest one is to "make it manageable". Like in the case where you want to push_back into two vectors in a transactional-like fashion: vec1.push_back(Connection{params}); scope_guard pushGuard {[&]{ vec1.pop_back(); }} vec2.push_back(Storage{params}); pushGuard.deactivate(); The problem is contained, so I do not mind the call to deactivate(). But without the scope_guard, I would have to define my own class that does a pop-back in the destructor. > > Yes, you can manually (de)activate the guard in small and contained > cases, but in general I would very much prefer it to work automatically. > Otherwise, it quickly becomes a maintenance nightmare that it was > supposed to fix. > True. Therefore in my code I would contain the code that requires a guard. (In general, I prefer RAII.) But even contained cases need a scope guard. So, the trade-off is this: scope_fail: - requires no manual deactivate scope_guard with deactivate(): - works uniformly and unsurprisingly in all contexts, including coroutines - is fast. I would recommend that this trade-off is documented. Regards, &rzej; > > > Regarding failure conditions other than exceptions, the problem with > > coroutines may still appear if a thread-local storage is used, such > > as errno. > > errno is volatile (not in core C++ terms but in terms of it changing its > value in various non-obvious ways), so you would normally read its value > into a local variable immediately after a syscall for testing before > returning. It is that local variable that you check in the scope guard, > not errno itself. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 2

Typo in Mysql URL on release page
by Tim Haines 14 Apr '23

14 Apr '23

The link to Mysql on the release page ( https://www.boost.org/users/history/version_1_82_0.html) points to https://www.boost.org/doc/libs/1_82_0/libs/msyql/ ^^ Thanks. - Tim

1 0

Re: [boost] about boost::math
by Matt Borland 14 Apr '23

14 Apr '23

> a) __STDCPP_FLOAT80_T__ > With C++23 we get std::floatN_t-types, which are displayed by the macros __STDCPP_FLOATn_T__. However I miss __STDCPP_FLOAT80_T__, which has its justification/relevance. One could retrofit this > #if defined(BOOST_CSTDFLOAT_FLOAT80_NATIVE_TYPE) > #define __STDCPP_FLOAT80_T__ > namespace std > { > using float80_t = boost::float80_t; > } > #endif > Would this be useful/wanted like this? From the proposal the fixed width types are not allowed to be typedefs of the existing types https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html#exten…. Sections 5.3 - 5.5 also cover a whole host of conversion rules that would be unsupported. I do not believe this is something we can do at the library level. > b) complex-functions > Since C++11 there are the functions abs, asin/h, acos/h, atan/h. These are also defined in boost/math/complex.hpp. But now with 1.82 boost::math is based on C++14, which makes these manual implementations obsolete -> boost/math/complex.hpp can be removed. These functions are all explicitly marked deprecated, but we do not have a timeline for removal. > c) constexpr > I want to upgrade some functions in boost::math. How should/can I handle constexpr there? My problem is: > - in gcc almost all math functions are constexpr > - otherwise only some math functions with C++23 are constexpr > Now it would be suboptimal not to use constexpr just because it is currently not in the standard. > - If I don't define the additional functions as constexpr or stick strictly to the standard, performance might be wasted, which I don't want. > - Can I simply define the additional functions with constexpr/BOOST_CXX14_CONSTEXPR? In case of an error there will be the standard-error "not constexpr". All of the cmath functions that are specified to be constexpr in C++23 can be used with C++17 here: https://github.com/boostorg/math/tree/develop/include/boost/math/ccmath. If you would like to submit PRs for additional functions they are welcome. With the transcendental functions accuracy quickly becomes an issue: https://members.loria.fr/PZimmermann/papers/accuracy.pdf > d) implementation > In https://www.boost.org/doc/libs/1_82_0_beta1/libs/math/doc/html/math_toolkit… you describe how to implement a new math function. Is this still up to date or is it necessary for simple functions? E.g. cot -> 1/tan. That is generally correct. If this is for the implementation of constexpr cmath functions I would follow the implementations that can be found in the linked ccmath folder. Matt

2 3

Recent videos on boost.asio from Utah C++ Programmers
by Richard 14 Apr '23

14 Apr '23

Hi Team, I sent these to boost-users, but they've been held up in moderation. It was suggested that I should also share them on this list. Cheers, -- Richard =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Subject: New video: Getting Started with Boost.Asio: Timers and Serial Ports --------- Utah Cpp Programmers has released a new video Getting Started with Boost.Asio: Timers and Serial Ports <https://www.youtube.com/watch?v=XB3uEit5R_Y> I/O operations are inherently asynchronous -- we don't know when input will arrive and when output will be generated. Network I/O can be particularly bothersome because of the long delays between sending a request and obtaining the response. Boost.Asio is a cross-platform C++ library for network and low-level I/O programming that provides developers with a consistent asynchronous model using a modern C++ approach. Boost.Asio covers timers, serial ports, files, pipes and TCP/IP networking. This month, Richard Thomson will give us an introduction to Boost.Asio concepts and asynchronous programming with this library. We'll look at how to use timers to notify our application of time passing and how to talk to serial ports asynchronously. Other Utah Cpp Programmers videos: <https://www.youtube.com/@UtahCppProgrammers> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Subject: New video on TCP/IP Networking with Boost.Asio --------- Utah C++ Programmers has released a new video TCP/IP Networking with Boost.Asio <https://www.youtube.com/watch?v=tyDWXT8-Ykc> Boost.Asio is a cross-platform C++ library for network and low-level I/O programming that provides developers with a consistent asynchronous model using a modern C++ approach. This month, Richard Thomson will continue our look at Boost.Asio with a look at TCP/IP networking. We'll look at how to implement an NNTP (Network News Transport Protocol) client using Boost.Asio. NNTP is a line-oriented protocol for reading usenet news articles. This will give us insight into all the typical issues involved in a TCP/IP networking application: - How do we resolve a host name into an IP address? - How do we establish a long-lived connection to an NNTP server? - How do we handle the arbitrarily large amounts of data from an NNTP server that arrives asynchronously? - How do we coordinate user input with NNTP I/O? - How do we handle unexpected network errors? -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

1 0

Re: [boost] quadmath as distinct library?
by Gero Peterhoff 14 Apr '23

14 Apr '23

Am 12.04.23 um 15:18 schrieb Christopher Kormanyos via Boost: > >>>> * 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 >> Chris Kormanyos and I have discussed writing a software> implementation of binary128 that could be used cross> platform. That would be more valuable as a separate library. > It is good to read this discussion. > Historically, it all went like this... > > When we started <boost/cstdfloat.hpp>, we wereinterested in specifying floating-point types havingfixed-widths. This proposal was abandoned in the2013 timeframe, but recently picked up and broughtinto C++23 with some new stuff. > Around that time, we also "invented" Multiprecision,which came into Boost 1.53, basically with the numberbackend and cpp_dec_float only. We went on(with lots and lots of work primiarly by John) toadd several backends to Multiprecision, one ofthem being Multiprecision's float128 backend. > So indeed, we have two 128 bit floats hangingaround, yet form some platforms such as thepopular MSVC, we have zero 128-bit floatimplementations. > Writing a uniform, cross-platform implementationcombined with aliases and/or seamless use inMultiprecision is, I believe, something of interestto us all. But i believe we need some specifyingwork and a few trial implementations in order tosee how all of this should fit in together nicelain a post C++23 domain. > This is good discussion and I think we will followup on it. > Chris > > On Wednesday, April 12, 2023 at 01:12:01 PM GMT+2, Matt Borland via Boost <boost(a)lists.boost.org> wrote: > > > On Apr 11, 2023, at 8:09 PM, Gero Peterhoff via Boost <boost(a)lists.boost.org> wrote: >> >> Am 13.03.23 um 13:33 schrieb John Maddock via Boost: >> >>> 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. >> >> I mean this canonically. >> Advantages: >> - For both compilers (gcc/intel) the functions/limits can be provided directly, without the mass #define/#undef function-macros. >> - Clean separation and/or Konsolidierugn of the __float128 types: >> a) gcc: __float128 > > GCC also provides support for __ibm128 on PowerPC platforms. We don’t have any support for it because there has been no demand signal. > >> b) intel: Windows _Qaud -> __float128, !Windows -> __float128 (https://community.intel.com/t5/Intel-C-Compiler/C-Compiler-128-bit-floating…) >> So there is only one type __float128. >> - Clean/mature standard functions can be provided for IO. > >> Disadvantages: >> - One-time(!) effort to update dependent libs. > > Boost.Multiprecision is already available without the rest of Boost: https://github.com/boostorg/multiprecision/releases so there isn’t much bloat in the way it can be consumed now. Chris Kormanyos and I have discussed writing a software implementation of binary128 that could be used cross platform. That would be more valuable as a separate library. > > Matt Hi Matt, Hi Chris, Thanks for your comments. However, I didn't want this to be that elaborate, I just wanted to define a unique C++ interface for __float128. Right now, IO functions are spread across different header files with divergent functionality, for example: 1) boost/math/cstdfloat/cstdfloat_cmath.hpp: non-template operator<< 2) boost/math/cstdfloat/cstdfloat_iostream.hpp: operator<< operator>> 3) There are quite a few forward declarations/defines in boost/multiprecision/float128.hpp, although they are available in boost/math/cstdfloat/cstdfloat_cmath.hpp. Also, float128_backend::str seems to support std::hexfloat, which 1+2 do not. Therefore it would make sense to provide quadmath for __float128 (or intel _Quad) as a sub-library of boost.math to unify this and provide more functions (e.g. C++17 from_chars/to_chars, to_w/string). boost/multiprecision/float128.hpp could then simply use this (#include <boost/math/quadmath.hpp>). I've started with this before (see attachment); for gcc it's halfway ok, intel doesn't work. cu Gero

1 0

Re: [boost] [scope] Proposing Boost.Scope
by Andrzej Krzemienski 14 Apr '23

14 Apr '23

czw., 13 kwi 2023 o 10:43 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > On 4/13/23 06:08, Darrell Wright via Boost wrote: > > One thing I learned in my own replacement is that exit_success is > heavily penalized on MSVC, even when there is no possible exception, > because of the call to uncaught_exceptions that isn’t optimized. It’s a > good thing to document, if not already, as it is surprising. > > Well, a certain amount of overhead is expected, since the added > condition is there and not likely to be optimized away. However, I would > expect uncaught_exceptions() to be cheap, as it should simply read an > integer from TLS. It looks like the call to std::uncaught_exceptions() is not optimized out, even in -O3: https://godbolt.org/z/PYEjP5PYY > I wonder how std::uncaught_exceptions() compares to > our custom implementation in boost::core::uncaught_exceptions(). > Perhaps, I should benchmark it. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Master branch is NOT yet open
by Marshall Clow 14 Apr '23

14 Apr '23

I have some more work to do to start the 1.83.0 release cycle. I will post here when the master branch is open (sometime tomorrow) Thank you for your patience. — Marshall

1 0

[release] Boost 1.82.0
by Marshall Clow 14 Apr '23

14 Apr '23

Release 1.82.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contain numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.82.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. -- The Boost Release Team Marshall Clow, Glen Fernandes

1 0

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

13 Apr '23

On 4/13/23 06:07, Francois Kritzinger via Boost wrote: > On 2023/03/13 14:07, Andrey Semashev via Boost wrote: >> 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. > > However Boost.Log also depends on Boost.Spirit which depends on > Boost.Regex so that's a hard dependency. To my knowledge, Boost.Log doesn't use the bits of Boost.Spirit that use Boost.Regex. This means, if you build Boost.Log that uses e.g. std::regex internally, it will not link with Boost.Regex.

1 0

Re: [boost] [scope] Proposing Boost.Scope
by Andrey Semashev 13 Apr '23

13 Apr '23

On 4/13/23 06:08, Darrell Wright via Boost wrote: > One thing I learned in my own replacement is that exit_success is heavily penalized on MSVC, even when there is no possible exception, because of the call to uncaught_exceptions that isn’t optimized. It’s a good thing to document, if not already, as it is surprising. Well, a certain amount of overhead is expected, since the added condition is there and not likely to be optimized away. However, I would expect uncaught_exceptions() to be cheap, as it should simply read an integer from TLS. I wonder how std::uncaught_exceptions() compares to our custom implementation in boost::core::uncaught_exceptions(). Perhaps, I should benchmark it.

1 0

Re: [boost] Boost configuration problem
by Peter Dimov 13 Apr '23

13 Apr '23

Дмитрий Архипов wrote: > How did you install Boost? This > > boost_filesystem.lib (shared, Boost_USE_STATIC_LIBS=ON) > > Seems like you're trying to use a static library, but only a shared library was > installed. https://anaconda.org/conda-forge/boost-cpp would be my guess. > чт, 13 апр. 2023 г., 06:17 Raivo Rebane via Boost <boost(a)lists.boost.org>: ...

1 0

Re: [boost] Boost configuration problem
by Дмитрий Архипов 13 Apr '23

13 Apr '23

How did you install Boost? This > boost_filesystem.lib (shared, Boost_USE_STATIC_LIBS=ON) Seems like you're trying to use a static library, but only a shared library was installed. чт, 13 апр. 2023 г., 06:17 Raivo Rebane via Boost <boost(a)lists.boost.org>: > Hello, > > May be I am in wrong list, but I didnt get answer for week from bugs list. > > May be anybody can help me ? > > I got following error from boost configuration and I can't go forward > > CMake gives configuration errors : > > CMake Error at > C:/Users/Raivo/miniconda3/Library/lib/cmake/Boost-1.78.0/BoostConfig.cmake:141 > > (find_package): > Found package configuration file: > > C:/Users/Raivo/miniconda3/Library/lib/cmake/boost_filesystem-1.78.0/boost_filesystem-config.cmake > > > > but it set boost_filesystem_FOUND to FALSE so package > "boost_filesystem" is > considered to be NOT FOUND. Reason given by package: > > No suitable build variant has been found. > > The following variants have been tried and rejected: > > * boost_filesystem.lib (shared, Boost_USE_STATIC_LIBS=ON) > > Still Boost is useless for me as I wanted to build Point CLoud Lib, bud > CMake stops on these errors. > > How to overcome of this error or what I have to do to go forwwsrd ? > > Regards > Raivo > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Boost configuration problem
by Peter Dimov 13 Apr '23

13 Apr '23

Raivo Rebane wrote: > Hello, > > May be I am in wrong list, but I didnt get answer for week from bugs list. > > May be anybody can help me ? > > I got following error from boost configuration and I can't go forward > > CMake gives configuration errors : > > CMake Error at > C:/Users/Raivo/miniconda3/Library/lib/cmake/Boost- > 1.78.0/BoostConfig.cmake:141 > (find_package): > Found package configuration file: > > C:/Users/Raivo/miniconda3/Library/lib/cmake/boost_filesystem- > 1.78.0/boost_filesystem-config.cmake > > > but it set boost_filesystem_FOUND to FALSE so package "boost_filesystem" > is > considered to be NOT FOUND. Reason given by package: > > No suitable build variant has been found. > > The following variants have been tried and rejected: > > * boost_filesystem.lib (shared, Boost_USE_STATIC_LIBS=ON) The error is exactly as it says. The Boost package that you're using only has shared libraries (e.g. bin/boost_filesystem.dll and its corresponding import library lib/boost_filesystem.lib), but the CMake variable Boost_USE_STATIC_LIBS is set to ON, requesting static libraries (such as lib/libboost_filesystem.lib, which you don't have.)

1 0

[release] Boost 1.82.0 Release Candidate 2 is available
by Löw, Tobias (Iqony Solutions GmbH) 13 Apr '23

13 Apr '23

Compiling the range mfc-iterators with msvc 143 (VS2022) results in a compilation error. It would be nice, if https://github.com/boostorg/range/pull/144 was addressed before the final release. Compilation error with msvc 143, std=c++latest: 1>D:\boost\range\detail\microsoft.hpp(626,33): error C2440: 'return': cannot convert from 'const void *' to 'const void *&' 1>D:\boost\range\detail\microsoft.hpp(624,1): message : while compiling class template member function 'const void *&boost::range_detail_microsoft::list_iterator<const X,const void *,boost::use_default,boost::use_default>::dereference(void) const' 1> with 1> [ 1> X=CPtrList 1> ] 1>D:\boost\iterator\iterator_facade.hpp(631,11): message : see reference to function template instantiation 'const void *&boost::range_detail_microsoft::list_iterator<const X,const void *,boost::use_default,boost::use_default>::dereference(void) const' being compiled 1> with 1> [ 1> X=CPtrList 1> ] 1>D:\boost\range\mfc.hpp(881,1): message : see reference to class template instantiation 'boost::range_detail_microsoft::list_iterator<const X,const void *,boost::use_default,boost::use_default>' being compiled 1> with 1> [ 1> X=CPtrList 1> ] Thanks Tobias

1 0

Re: [boost] quadmath as distinct library?
by Christopher Kormanyos 12 Apr '23

12 Apr '23

>>>> * 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 > Chris Kormanyos and I have discussed writing a software> implementation of binary128 that could be used cross> platform. That would be more valuable as a separate library. It is good to read this discussion. Historically, it all went like this... When we started <boost/cstdfloat.hpp>, we wereinterested in specifying floating-point types havingfixed-widths. This proposal was abandoned in the2013 timeframe, but recently picked up and broughtinto C++23 with some new stuff. Around that time, we also "invented" Multiprecision,which came into Boost 1.53, basically with the numberbackend and cpp_dec_float only. We went on(with lots and lots of work primiarly by John) toadd several backends to Multiprecision, one ofthem being Multiprecision's float128 backend. So indeed, we have two 128 bit floats hangingaround, yet form some platforms such as thepopular MSVC, we have zero 128-bit floatimplementations. Writing a uniform, cross-platform implementationcombined with aliases and/or seamless use inMultiprecision is, I believe, something of interestto us all. But i believe we need some specifyingwork and a few trial implementations in order tosee how all of this should fit in together nicelain a post C++23 domain. This is good discussion and I think we will followup on it. Chris On Wednesday, April 12, 2023 at 01:12:01 PM GMT+2, Matt Borland via Boost <boost(a)lists.boost.org> wrote: > On Apr 11, 2023, at 8:09 PM, Gero Peterhoff via Boost <boost(a)lists.boost.org> wrote: > > Am 13.03.23 um 13:33 schrieb John Maddock via Boost: > >> 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. > > I mean this canonically. > Advantages: > - For both compilers (gcc/intel) the functions/limits can be provided directly, without the mass #define/#undef function-macros. > - Clean separation and/or Konsolidierugn of the __float128 types: > a) gcc: __float128 GCC also provides support for __ibm128 on PowerPC platforms. We don’t have any support for it because there has been no demand signal. > b) intel: Windows _Qaud -> __float128, !Windows -> __float128 (https://community.intel.com/t5/Intel-C-Compiler/C-Compiler-128-bit-floating…) > So there is only one type __float128. > - Clean/mature standard functions can be provided for IO. > Disadvantages: > - One-time(!) effort to update dependent libs. Boost.Multiprecision is already available without the rest of Boost: https://github.com/boostorg/multiprecision/releases so there isn’t much bloat in the way it can be consumed now. Chris Kormanyos and I have discussed writing a software implementation of binary128 that could be used cross platform. That would be more valuable as a separate library. Matt _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[release] Boost 1.82.0 Release Candidate 2 is available
by don la dieu 12 Apr '23

12 Apr '23

It would be nice if https://github.com/boostorg/functional/pull/21 was addressed before final release. Alternatively see the below error. $ brew info boost llvm | grep bottled ==> boost: stable 1.81.0 (bottled), HEAD ==> llvm: stable 16.0.1 (bottled), HEAD [keg-only] $ clang++ --version Homebrew clang version 16.0.1 Target: arm64-apple-darwin21.6.0 Thread model: posix InstalledDir: /opt/homebrew/opt/llvm/bin $ cat functional_is_b0rk.cc #include <boost/functional.hpp> int main() {} $ clang++ -O0 -g -I/opt/homebrew/include -c functional_is_b0rk.cc In file included from functional_is_b0rk.cc:1: /opt/homebrew/include/boost/functional.hpp:45:24: error: no member named 'unary_function' in namespace 'std'; did you mean '__unary_function'? using std::unary_function; ~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/opt/llvm/bin/../include/c++/v1/__functional/unary_function.h:46:1: note: '__unary_function' declared here using __unary_function = __unary_function_keep_layout_base<_Arg, _Result>; ^ In file included from functional_is_b0rk.cc:1: /opt/homebrew/include/boost/functional.hpp:46:24: error: no member named 'binary_function' in namespace 'std'; did you mean '__binary_function'? using std::binary_function; ~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/opt/llvm/bin/../include/c++/v1/__functional/binary_function.h:49:1: note: '__binary_function' declared here using __binary_function = __binary_function_keep_layout_base<_Arg1, _Arg2, _Result>; ^ In file included from functional_is_b0rk.cc:1: /opt/homebrew/include/boost/functional.hpp:180:45: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? : public boost::functional::detail::unary_function<typename unary_traits<Predicate>::argument_type,bool> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:214:45: error: no template named 'binary_function' in namespace 'boost::functional::detail'; did you mean '__binary_function'? : public boost::functional::detail::binary_function< ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/include/boost/functional.hpp:46:24: note: '__binary_function' declared here using std::binary_function; ^ /opt/homebrew/include/boost/functional.hpp:252:45: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? : public boost::functional::detail::unary_function< ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:299:45: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? : public boost::functional::detail::unary_function< ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:345:57: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? class mem_fun_t : public boost::functional::detail::unary_function<T*, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:361:58: error: no template named 'binary_function' in namespace 'boost::functional::detail'; did you mean '__binary_function'? class mem_fun1_t : public boost::functional::detail::binary_function<T*, A, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/include/boost/functional.hpp:46:24: note: '__binary_function' declared here using std::binary_function; ^ /opt/homebrew/include/boost/functional.hpp:377:63: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? class const_mem_fun_t : public boost::functional::detail::unary_function<const T*, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:393:64: error: no template named 'binary_function' in namespace 'boost::functional::detail'; did you mean '__binary_function'? class const_mem_fun1_t : public boost::functional::detail::binary_function<const T*, A, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/include/boost/functional.hpp:46:24: note: '__binary_function' declared here using std::binary_function; ^ /opt/homebrew/include/boost/functional.hpp:438:61: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? class mem_fun_ref_t : public boost::functional::detail::unary_function<T&, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:454:62: error: no template named 'binary_function' in namespace 'boost::functional::detail'; did you mean '__binary_function'? class mem_fun1_ref_t : public boost::functional::detail::binary_function<T&, A, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/include/boost/functional.hpp:46:24: note: '__binary_function' declared here using std::binary_function; ^ /opt/homebrew/include/boost/functional.hpp:470:67: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? class const_mem_fun_ref_t : public boost::functional::detail::unary_function<const T&, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:487:68: error: no template named 'binary_function' in namespace 'boost::functional::detail'; did you mean '__binary_function'? class const_mem_fun1_ref_t : public boost::functional::detail::binary_function<const T&, A, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/include/boost/functional.hpp:46:24: note: '__binary_function' declared here using std::binary_function; ^ /opt/homebrew/include/boost/functional.hpp:533:73: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? class pointer_to_unary_function : public boost::functional::detail::unary_function<Arg,Result> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:557:74: error: no template named 'binary_function' in namespace 'boost::functional::detail'; did you mean '__binary_function'? class pointer_to_binary_function : public boost::functional::detail::binary_function<Arg1,Arg2,Result> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/include/boost/functional.hpp:46:24: note: '__binary_function' declared here using std::binary_function; ^ 16 errors generated.

1 0

Re: [boost] quadmath as distinct library?
by Matt Borland 12 Apr '23

12 Apr '23

> On Apr 11, 2023, at 8:09 PM, Gero Peterhoff via Boost <boost(a)lists.boost.org> wrote: > > Am 13.03.23 um 13:33 schrieb John Maddock via Boost: > >> 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. > > I mean this canonically. > Advantages: > - For both compilers (gcc/intel) the functions/limits can be provided directly, without the mass #define/#undef function-macros. > - Clean separation and/or Konsolidierugn of the __float128 types: > a) gcc: __float128 GCC also provides support for __ibm128 on PowerPC platforms. We don’t have any support for it because there has been no demand signal. > b) intel: Windows _Qaud -> __float128, !Windows -> __float128 (https://community.intel.com/t5/Intel-C-Compiler/C-Compiler-128-bit-floating…) > So there is only one type __float128. > - Clean/mature standard functions can be provided for IO. > Disadvantages: > - One-time(!) effort to update dependent libs. Boost.Multiprecision is already available without the rest of Boost: https://github.com/boostorg/multiprecision/releases so there isn’t much bloat in the way it can be consumed now. Chris Kormanyos and I have discussed writing a software implementation of binary128 that could be used cross platform. That would be more valuable as a separate library. Matt

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Glen Fernandes 12 Apr '23

12 Apr '23

On Tue, Apr 11, 2023 at 6:07 PM Andrey Semashev via Boost < boost(a)lists.boost.org> wrote: > On 4/12/23 01:02, Marshall Clow wrote: > > On Apr 11, 2023, at 2:17 PM, Andrey Semashev via Boost < > boost(a)lists.boost.org> wrote: > >> > >> On 4/10/23 17:36, Marshall Clow via Boost wrote: > >>> The second release candidates for the 1.82.0 release are now available > at: > >>> <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ < > https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> > >>> > >>> There is only one change from RC1 - a fix to ASIO that caused some > compile failures. > >>> Thanks to Ruben Perez for the report, and to Chris for the fix. > >>> > >>> > >>> The SHA256 checksums are as follows: > >>> > >>> 66a469b6e608a51f8347236f4912e27dc5c60c60d7d53ae9bfe4683316c6f04c > boost_1_82_0_rc2.tar.gz > >>> f7c9e28d242abcd7a2c1b962039fcdd463ca149d1883c3a950bbcc0ce6f7c6d9 > boost_1_82_0_rc2.zip > >>> a6e1ab9b0860e6a2881dd7b21fe9f737a095e5f33a3a874afc6a345228597ee6 > boost_1_82_0_rc2.tar.bz2 > >>> e72ff100482d4b371327b6c550dbd244d49c0186860ccc3b8c093dd621537e39 > boost_1_82_0_rc2.7z > >>> > >>> > >>> 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. > >> > >> I would like the following last minute fix to be merged to > >> Boost.Filesystem master: > >> > >> > https://github.com/boostorg/filesystem/commit/176fce8e4d2016e864a0b9193cc4e… > >> > >> This should fix compilation on OpenBSD due to broken -Wl,--no-undefined > >> flag on this platform. > >> > >> This problem was reported very late: > >> > >> https://github.com/boostorg/filesystem/issues/283 > > > > Is this a new problem in this release? > > Yes. > If this is the only issue, I think we may put a Filesystem patch for OpenBSD users on the website instead of producing an RC3.

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Marshall Clow 11 Apr '23

11 Apr '23

On Apr 11, 2023, at 2:17 PM, Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > > On 4/10/23 17:36, Marshall Clow via Boost wrote: >> The second release candidates for the 1.82.0 release are now available at: >> <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> >> >> There is only one change from RC1 - a fix to ASIO that caused some compile failures. >> Thanks to Ruben Perez for the report, and to Chris for the fix. >> >> >> The SHA256 checksums are as follows: >> >> 66a469b6e608a51f8347236f4912e27dc5c60c60d7d53ae9bfe4683316c6f04c boost_1_82_0_rc2.tar.gz >> f7c9e28d242abcd7a2c1b962039fcdd463ca149d1883c3a950bbcc0ce6f7c6d9 boost_1_82_0_rc2.zip >> a6e1ab9b0860e6a2881dd7b21fe9f737a095e5f33a3a874afc6a345228597ee6 boost_1_82_0_rc2.tar.bz2 >> e72ff100482d4b371327b6c550dbd244d49c0186860ccc3b8c093dd621537e39 boost_1_82_0_rc2.7z >> >> >> 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. > > I would like the following last minute fix to be merged to > Boost.Filesystem master: > > https://github.com/boostorg/filesystem/commit/176fce8e4d2016e864a0b9193cc4e… > > This should fix compilation on OpenBSD due to broken -Wl,--no-undefined > flag on this platform. > > This problem was reported very late: > > https://github.com/boostorg/filesystem/issues/283 Is this a new problem in this release? — Marshall

2 1

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Andrey Semashev 11 Apr '23

11 Apr '23

On 4/10/23 17:36, Marshall Clow via Boost wrote: > The second release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> > > There is only one change from RC1 - a fix to ASIO that caused some compile failures. > Thanks to Ruben Perez for the report, and to Chris for the fix. > > > The SHA256 checksums are as follows: > > 66a469b6e608a51f8347236f4912e27dc5c60c60d7d53ae9bfe4683316c6f04c boost_1_82_0_rc2.tar.gz > f7c9e28d242abcd7a2c1b962039fcdd463ca149d1883c3a950bbcc0ce6f7c6d9 boost_1_82_0_rc2.zip > a6e1ab9b0860e6a2881dd7b21fe9f737a095e5f33a3a874afc6a345228597ee6 boost_1_82_0_rc2.tar.bz2 > e72ff100482d4b371327b6c550dbd244d49c0186860ccc3b8c093dd621537e39 boost_1_82_0_rc2.7z > > > 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. I would like the following last minute fix to be merged to Boost.Filesystem master: https://github.com/boostorg/filesystem/commit/176fce8e4d2016e864a0b9193cc4e… This should fix compilation on OpenBSD due to broken -Wl,--no-undefined flag on this platform. This problem was reported very late: https://github.com/boostorg/filesystem/issues/283

1 0

Boost docs
by Peter Turcan 11 Apr '23

11 Apr '23

Hi, This week I joined CppAlliance as a technical writer - just introducing myself here! I am pumped to be writing some C++ code after several years hiatus. The last major project I wrote in C++ was a wargame that would cope with battle data from either the Napoleonic wars, or the American Civil War, and was called Battalia. It is still around in archive sites such as: https://archive.org/details/wargamer-depot_battalia Mostly I write developer documentation and tutorials. The work I enjoyed the most was writing the SDK for Microsoft Flight Simulator (and taught myself instrument flying in the process), the User Guides and SDK for WorldWide Telescope (an astronomy viewing program that involved working with NASA on Mars imagery data), and writing a range of developer tutorials for Azure IoT, Azure Search and Azure Maps. I was the main writer at Microsoft for the DirectX 12 documentation - though that was a brutally tough SDK to actually work with. Most developers stuck with DirectX 11 - not sure where Microsoft is now on its graphics APIs. At CppAlliance I hope to add value to the documentation on the libraries where I can - perhaps adding examples, better navigation, and more complete descriptions of parameters, edge-cases, errors - the usual suspects that are often missing from documentation but are sorely needed by developers. Also, I plan on getting hardcore with the introductions to each library. The question that should be answered in introductions to any library (or any SDK) is the "why" question. Why should I be interested in this library? What is the problem that I have that the library is solving? This is often missing. A typical introduction might answer the "What" question - such as "this particular piece of software converts A into B", and the "How" question (what tools and setup is needed), but avoids the why question: "why should I be interested in converting A into B". The answer might be: "this library converts A into B to provide your data with an additional level of security, when the data is communicated over the internet." By answering the why question, any developer will know immediately whether to continue reading, or look elsewhere. Another aspect of documentation to look at is style. For API reference type documentation (interfaces, functions, parameters), mostly a neutral style works well - just say exactly what is going on. For guide or more conceptual material, perhaps a chattier style is more appropriate - short sharp sentences, some wit and wisdom, less formality - like talking to a knowledgeable buddy. You probably have some great ideas too on adding value to the existing Boost documentation - happy to hear any and all feedback! - best Peter

1 0

Re: [boost] quadmath as distinct library?
by Gero Peterhoff 11 Apr '23

11 Apr '23

Am 13.03.23 um 13:33 schrieb John Maddock via Boost: > 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. I mean this canonically. Advantages: - For both compilers (gcc/intel) the functions/limits can be provided directly, without the mass #define/#undef function-macros. - Clean separation and/or Konsolidierugn of the __float128 types: a) gcc: __float128 b) intel: Windows _Qaud -> __float128, !Windows -> __float128 (https://community.intel.com/t5/Intel-C-Compiler/C-Compiler-128-bit-floating…) So there is only one type __float128. - Clean/mature standard functions can be provided for IO. Disadvantages: - One-time(!) effort to update dependent libs. Gero

1 0

about boost::math
by Gero Peterhoff 11 Apr '23

11 Apr '23

a) __STDCPP_FLOAT80_T__ With C++23 we get std::floatN_t-types, which are displayed by the macros __STDCPP_FLOATn_T__. However I miss __STDCPP_FLOAT80_T__, which has its justification/relevance. One could retrofit this #if defined(BOOST_CSTDFLOAT_FLOAT80_NATIVE_TYPE) #define __STDCPP_FLOAT80_T__ namespace std { using float80_t = boost::float80_t; } #endif Would this be useful/wanted like this? b) complex-functions Since C++11 there are the functions abs, asin/h, acos/h, atan/h. These are also defined in boost/math/complex.hpp. But now with 1.82 boost::math is based on C++14, which makes these manual implementations obsolete -> boost/math/complex.hpp can be removed. c) constexpr I want to upgrade some functions in boost::math. How should/can I handle constexpr there? My problem is: - in gcc almost all math functions are constexpr - otherwise only some math functions with C++23 are constexpr Now it would be suboptimal not to use constexpr just because it is currently not in the standard. - If I don't define the additional functions as constexpr or stick strictly to the standard, performance might be wasted, which I don't want. - Can I simply define the additional functions with constexpr/BOOST_CXX14_CONSTEXPR? In case of an error there will be the standard-error "not constexpr". d) implementation In https://www.boost.org/doc/libs/1_82_0_beta1/libs/math/doc/html/math_toolkit… you describe how to implement a new math function. Is this still up to date or is it necessary for simple functions? E.g. cot -> 1/tan. thx Gero

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Ruben Perez 11 Apr '23

11 Apr '23

On Mon, 10 Apr 2023 at 16:37, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > The second release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> > > There is only one change from RC1 - a fix to ASIO that caused some compile failures. > Thanks to Ruben Perez for the report, and to Chris for the fix. I have successfully built the libraries under clang-15, on Ubuntu 22.04. I can confirm that there are no problems building Boost.MySQL examples. Regards, Ruben.

1 0