- Boost - lists.boost.org

Has testing on msvc been dropped?
by Daniela Engert 01 Mar '23

01 Mar '23

Hi y'all! I've noticed that e.g. Boost.Log no longer compiles on msvc 19.35 (i.e. VS2022 update 5). Looking at the test matrix to figure out where the problem might lie, I couldn't find any column with the test results of *any* msvc version, lest the current one. Is there a reason for no longer running the tests with msvc compilers? thank, Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

6 21

Re: [boost] Delivery Status Notification (Failure)
by Andre Marin 26 Feb '23

26 Feb '23

Hi, I'm interested in becoming a maintainer. I'm interested in the following projects: - Algorithm <https://www.boost.org/doc/libs/release/libs/algorithm/> - Python <https://www.boost.org/doc/libs/release/libs/python/> - Stl_interfaces <https://www.boost.org/doc/libs/release/libs/stl_interfaces/> - Type Erasure <https://www.boost.org/doc/libs/release/libs/type_erasure/> I'm trying to email olivas(a)icecube.umd.edu, per the Boost website but it's not going through. I'm looking for some guidance. I've included the previous request and email error in this email. Thank you, *Andre Marin * *m:* (832) 495-3545 *e:* andre(a)alexamarin.com <https://www.linkedin.com/in/andremarin629/> On Sun, Feb 26, 2023 at 11:46 AM Mail Delivery Subsystem < mailer-daemon(a)googlemail.com> wrote: > [image: Error Icon] > Address not found > Your message wasn't delivered to *olivas(a)icecube.umd.edu* because the > address couldn't be found, or is unable to receive mail. > The response from the remote server was: > > 550 5.1.1 <olivas(a)icecube.umd.edu>: Recipient address rejected: User > unknown in local recipient table > > > > ---------- Forwarded message ---------- > From: Andre Marin <andre(a)alexamarin.com> > To: olivas(a)icecube.umd.edu > Cc: > Bcc: > Date: Sun, 26 Feb 2023 11:46:03 -0600 > Subject: Boost Library Official Maintainer Program > Hi, > > I'm interested in becoming a maintainer. I'm interested in the following > projects: > > - Algorithm <https://www.boost.org/doc/libs/release/libs/algorithm/> > - Python <https://www.boost.org/doc/libs/release/libs/python/> > - Stl_interfaces > <https://www.boost.org/doc/libs/release/libs/stl_interfaces/> > - Type Erasure > <https://www.boost.org/doc/libs/release/libs/type_erasure/> > > > I've been limited to C++11 at work and I'm new to library contributions. > I'm not sure if there are more appropriate projects for noobs or areas of > need I couldn't find on the website. > > Thank you, > > *Andre Marin * > *m:* (832) 495-3545 > *e:* andre(a)alexamarin.com > <https://www.linkedin.com/in/andremarin629/> >

2 1

Future of boost::TypeTraits
by Gero Peterhoff 24 Feb '23

24 Feb '23

Hello, with the planned changes of the dependencies of the boost libraries to newer C++-standards, I would like to ask how this is planned for boost::TypeTraits. 1) In my opinion it would make sense to remove all TypeTraits that are already in the standard, and only provide those that do not exist in the standard (yet). Of course, this depends on the planned minimum standard for boost::TypeTraits. 2) If, on the other hand, boost::TypeTraits is to continue to work with C++03 (for which there may be reasons), however, quite a few adjustments must be made (for newer C++-standards) and bugs must be fixed. Examples: a) - no inline-variables are provided for C++17 (if useful), e.g. is_arithmetic_v - no concepts are provided for C++20 (if useful), e.g. arithmetic - that's why I already asked how to do this best without coming into (name)conflicts with existing structures/namespaces/etc. b) bugs - e.g. is_integral does not contain char8_t (if available) Probably my remarks also apply to other libraries, possibly TypeErasure, TypeIndex, TTI ... All this has to be reworked fundamentally and consolidated if necessary. best regards Gero

1 0

Boost Libraries and Dropping C++ Language Support
by Glen Fernandes 24 Feb '23

24 Feb '23

*Boost library authors and maintainers are free to drop support for old C++ standards in their libraries, at any time. * This includes libraries that other Boost libraries depend on. It even includes core libraries like Boost.Core or Boost.Static_Assert. We ask that maintainers do the right thing by all our users (which may include other Boost libraries) by announcing a future breakage *at least two Boost releases in advance*. When that eventual release time arrives, if Boost libraries are broken in older standards modes due to another Boost library dropping support, it will not block the Boost release. This means that we do not need to announce "Boost is dropping C++03" because Boost doesn't "support C++03" now as it is. It means that you, maintainer of Boost.X, should realize that you are free to announce that "Boost.X is dropping C++XY in version 1.Z" as you see fit. Boost in its infancy thrived because its libraries were on the cutting edge. Boost libraries today should similarly not be confined simply because other Boost libraries have chosen to depend on them. Furthermore, as Boost release managers we support authors exercising this freedom, and do not intend to impose any restrictions on what language support they must maintain. We will add a page to the Boost website stating the above formally. -- The release team (Glen Fernandes, Marshall Clow)

8 12

Boost 1.82.0 is now closed for new libraries and breaking changes
by Marshall Clow 23 Feb '23

23 Feb '23

Next deadline: On 1-Mar-2023 Boost 1.82.0 closes for major code changes. Still open for serious problem fixes and docs changes without release manager review. As always, the release calendar is at https://www.boost.org/development/ <https://www.boost.org/development/> - Boost release team

1 0

Fwd: Futex using boost, threads never wakeup
by tsoumplekas_giorgos 23 Feb '23

23 Feb '23

Subject: Futex using boost, threads never wakeup Hello all I posted the following question in stackoverflow https://stackoverflow.com/questions/75538799/futex-using-boost-threads-neve… 0 <https://stackoverflow.com/posts/75538799/timeline> I am studying about futex synchronisation Following up the manual <https://man7.org/linux/man-pages/man2/futex.2.html> , I tried to syncroniaze threads using boost futex However the threads never wake up #include <iostream>#include <atomic>#include <boost/fiber/detail/futex.hpp>#include <thread>#include <vector>#include <chrono>void wait(std::atomic<int> & futexp){ int one = 1; while(std::atomic_compare_exchange_strong(&futexp, &one, 0)) {} std::cout << std::this_thread::get_id() << "," << futexp.load() << std::endl; boost::fibers::detail::futex_wait(&futexp,0); // std::this_thread::sleep_for(std::chrono::milliseconds(5000)); }void fpost(std::atomic<int> & futexp){ int zero = 0; if (std::atomic_compare_exchange_strong(&futexp, &zero, 1)) { boost::fibers::detail::futex_wake(&futexp); } } std::atomic<int> futexp{1};int main() { std::vector<std::thread> vec; for(int i =0 ; i< 5;++i) { vec.emplace_back([]() { wait(futexp); fpost(futexp); }); } Code demo <https://godbolt.org/z/94hMsrW4a> I am using boost 1.66 and gcc 9.1 What goes wrong with this piece of code ?

3 2

Boost 1.82 closing for new libraries and breaking changes on 2023-02-24
by Glen Fernandes 22 Feb '23

22 Feb '23

On 02/24: Release branch will close for new libraries and breaking changes to existing libraries. Will still be open for bug fixes and other routine changes to all libraries without release manager review.

1 0

Dropping C++03 support (again)
by Peter Dimov 21 Feb '23

21 Feb '23

Greetings, I have a novel idea, let's drop C++03 support. The reasons to do that have been explicated already a number of times, e.g. in https://pdimov.github.io/articles/phasing_out_cxx03.html#_ongoing_costs_of_… but in brief: * C++03 is 20 years old. * A number of intra-Boost dependencies can be eliminated by using the standard equivalent of Boost components. This will help Boost to become "more modular". * Variadic templates allow us to remove the uses of Preprocessor and MPL, which are the primary contributor to slow Boost compilation times. * Almost no new C++03 development occurs in Boost at this point, so C++03 users do not need to upgrade their Boost. To that end, I propose the following: Boost release 1.82.0 is announced as the last one with C++03 support. If critical problems are found in it post-release, we will issue 1.82.1, 1.82.2 and so on, as appropriate (as C++03 users will not be able to just upgrade to 1.83.) Boost release 1.83.0 is announced to require C++11 at minimum. This means compilers that have all the C++11 standard headers, and support all the C++11 syntactic constructs and keywords without issuing errors. (E.g. VS2013 doesn't qualify because it doesn't support the `constexpr` or `noexcept` keywords.) This proposal should ultimately be approved and implemented by the Boost release managers; their opinions are particularly appreciated.

28 98

Mustache has been REJECTED from boost.
by Klemens Morgenstern 20 Feb '23

20 Feb '23

First I want to thank Peter for the submission and all reviewers for their participation in the review process. Please note that votes don't just get added up, but that details of every review, especially the time & effort spent on it, will influence how reviews get weighed. This review was close, with 3 REJECT, 4 Conditional ACCEPT and 0 ACCEPT votes. Rene, Jens and Darryl voted to accept on the condition that the documentation shall be improved/completed. Ruben's review had more complex conditions, among them this one: > 1. The partials argument must be typed according to the data structure it requires. Peter's response to this was "I don't see how this is supposed to be accomplished." I don't know what to make of the technical details here, but I don't think I can make something that might be impossible to accomplish a condition for acceptance. Julien & Vinnie voted to REJECT based on the state of the library, which makes me believe they might change their vote in a future review. Dmitry voted to REJECT based on the mustache language itself, and thus was the only one to reject boost.mustache in general. Based on the almost even split between conditional accept & reject and the lack of unconditional accepts, I decided to REJECT the library at this time. I hope Peter will submit an improved & extended version of this library for review in the future.

6 6

macro BOOST_HAS_CONCEPTS not work + namespace for concepts
by Gero Peterhoff 20 Feb '23

20 Feb '23

Hi, 1) the macro BOOST_HAS_CONCEPTS from <boost/config.hpp> (https://www.boost.org/doc/libs/1_81_0/libs/config/doc/html/boost_config/boo…) not work: https://godbolt.org/z/3G8vTrjcf 2) namespace for concepts Would it make sense to introduce a namespace *only* for concepts to avoid naming conflicts with existing classes? boost::concepts would be useful, but this is already used by the concept-check-library. Then would boost::Concepts be a good choice or could boost::concepts still be used? EG namespace boost { template <typename Type> struct my_trait ...; #if !defined(BOOST_NO_CXX17_INLINE_VARIABLES) template <typename Type> inline constexpr bool my_trait_v = my_trait<Type>::value; #endif #if concepts available namespace Concepts { template <typename Type> concept my_concept = my_trait_v<Type>; } // Concepts #endif } // boost thx Gero

4 10