- Boost - lists.boost.org

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

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Tom Kent 10 Apr '23

10 Apr '23

On Mon, Apr 10, 2023 at 9:36 AM 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. > > > 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. > > -- The Release managers > Looks good for 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 log here: https://gist.github.com/teeks99/3ffee2d9d3b93ec996f47ad7c38f64c1 Tom

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Matt Borland 10 Apr '23

10 Apr '23

> > 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 > > I have successfully built the libraries using Homebrew Clang 16.0.1 on an M1 Mac running macOS Ventura 13.3.1. Matt

1 0

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

10 Apr '23

On Apr 10, 2023, at 7:36 AM, 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. > > > 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 have successfully built the libraries in Mac OS 12.6.4, with "Apple clang version 14.0.0 (clang-1400.0.29.202)” and C++ 03/11/14/17/20/2b, on both x86 and ARM. — Marshall

1 0

[release] Boost 1.82.0 Release Candidate 2 is available
by Marshall Clow 10 Apr '23

10 Apr '23

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. -- The Release managers

1 0

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

09 Apr '23

niedz., 9 kwi 2023 o 00:28 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > On 4/7/23 18:42, Andrey Semashev wrote: > > On 4/7/23 15:55, Andrzej Krzemienski wrote: > >> czw., 6 kwi 2023 o 23:51 Andrey Semashev via Boost > >> <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> napisał(a): > >> > >> Thus I > >> wouldn't say scope_success/scope_fail are unimplementable - they > clearly > >> are - but that they are incompatible with coroutines. That is, these > >> scope guards will work as expected as long as you don't switch > >> coroutines within the guarded scope. > >> > >> Maybe this is just a question of the choice of words. > >> But the docs do not present the situation in this way. > >> > >> "Although it is possible to specify arbitrary condition function > >> objects, typically |scope_success > >> < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…>| > invokes its action when the scope is left normally (i.e. not via an > exception) and |scope_fail < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…>| > should typically be used to handle errors, including exceptions." > >> > >> This guarantee (when scope is exited not normally) cannot be satisfied > >> in general. One cannot use it in a coroutine: directly or indirectly. > >> One might not even know the context. > >> > >> "By default, |scope_success > >> < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…>| > will invoke its action if it is destroyed normally, |scope_fail < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…>| > - if it is destroyed due to an exception being thrown." > > > > Note the "typically". :) In this documentation I tried to describe these > > facilities in more or less simple language, describing the most typical > > use cases. For this simplicity, I had to omit some formalities and > > corner cases that would detract the reader from the main purpose and > > intended use case of the components. Perhaps, I should improve the > > wording, but I would still like the docs to be easily readable. > > > > And, as I admitted earlier, I completely forgot about coroutines. I will > > add a note about coroutenes in relation to the default failure condition > > used by scope_success/scope_fail. > > > >> (BTW, The synopsis in > >> > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail… > < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail… > > > >> does not indicate that there is any default Cond.) > > > > Hmm, for some reason Doxygen removed the default template arguments for > > scope_success/scope_fail. I'll see if I can fix this. Thanks for > noticing. > > I have updated the docs to fix those issues and added the note re. > coroutines. I've also improved wording so that the general discussion > does not focus on exceptions as much but rather failure and non-failure > conditions. > Thanks. 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. Regarding failure conditions other than exceptions, the problem with coroutines may still appear if a thread-local storage is used, such as errno. Regards, &rzej; > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 2