- Boost - lists.preview.boost.org

[release] Master branch is now open for bug fixes
by Marshall Clow 02 Apr '25

02 Apr '25

Hi, The master branch is now open for bug fixes, test and documentation changes, but please follow the policy described in: https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy The next deadline: On April 2nd, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ — The release managers

4 3

Boost::MQTT5 and boost 1.82.0?
by Georg Gast 31 Mar '25

31 Mar '25

Hi Boost, i read here [1] that boost::mqtt5 needs boost 1.82.0 but it is published with 1.88.0 Beta1 How to use boost::mqtt5 with boost 1.82.0? > Boost.MQTT5 is a header-only library. To use Boost.MQTT5 it requires the following: > > C++17 capable compiler > Boost 1.82 or later. In addition to Asio, we use other header- >only libraries. > OpenSSL. If you require an SSL connection by using boost::asio::ssl::stream. [1] https://www.boost.org/doc/libs/1_88_0_beta1/libs/mqtt5/doc/html/mqtt5/intro…

2 2

Issue fixed in context library that is not included in 1.88 beta release?
by Anders Axelsson 29 Mar '25

29 Mar '25

Hi, I stumbled upon a problem found in the 1.87.0 release (and also 1.88 beta1) The issue seems to have been resolved on the develop branch in the actual submodule repo quite some time ago by another developer, but it is yet not included in the top/super project. The ticket: https://github.com/boostorg/context/issues/297 I am very new to the community, so I don't really know what is the typical way of working here. it would be sad if we miss to include an important build issue in the next release just because of some administrative issues, so I am happy to help but like I said, I am not familiar with how I can do that. Any ideas?

3 3

Asio Beta changes are missing on the 1.88 Beta page
by Dennis Luehring 27 Mar '25

27 Mar '25

Asio is missing on the beta release page https://www.boost.org/users/history/version_1_88_0.html but there seem to be changes available for the beta https://www.boost.org/doc/libs/1_88_0_beta1/doc/html/boost_asio/history.html

1 0

Reminder: Master branch closes for the 1.88.0 release NEXT WEDNESDAY
by Marshall Clow 26 Mar '25

26 Mar '25

Also, if you have release notes, now’s the time to write them. — Marshall

1 0

release] Boost 1.88.0 beta 1 released
by Marshall Clow 16 Mar '25

16 Mar '25

Boost release 1.88.0 beta 1 is now available at: https://archives.boost.io/beta/1.88.0.beta1/source/ The SHA256 checksums are: bc4948bc664fde0c2142badae2679a42124b464dc58019250afe0ef57fd7763e boost_1_88_0_rc1.zip 3c334a9a743b68a35452b0223be8932fb39f26a6938382f9b9e625c4df99602c boost_1_88_0_rc1.tar.gz 9e42c0611500151d795d66a07ef0a21036c02d24678e2e887caf6d97fcbc25ca boost_1_88_0_rc1.tar.bz2 7faf60c4cb12ee90270e41716cf3735a8739016d7346983ce9f5e899e510b26d boost_1_88_0_rc1.7z Release notes (still need updates): https://www.boost.org/users/history/version_1_88_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

3 2

[release] Boost 1.88.0 Release Candidate 1 is available
by Marshall Clow 14 Mar '25

14 Mar '25

Available at: https://archives.boost.io/beta/1.88.0.beta1/source/ The SHA256 checksums are as follows: bc4948bc664fde0c2142badae2679a42124b464dc58019250afe0ef57fd7763e boost_1_88_0_b1_rc1.zip 3c334a9a743b68a35452b0223be8932fb39f26a6938382f9b9e625c4df99602c boost_1_88_0_b1_rc1.tar.gz 9e42c0611500151d795d66a07ef0a21036c02d24678e2e887caf6d97fcbc25ca boost_1_88_0_b1_rc1.tar.bz2 7faf60c4cb12ee90270e41716cf3735a8739016d7346983ce9f5e899e510b26d boost_1_88_0_b1_rc1.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

7 10

[proposal] OpenMethod library
by Jean-Louis Leroy 11 Mar '25

11 Mar '25

Hello Boost developers! I would like to propose my open-method library for inclusion in Boost. Open-methods are an elegant solution to the Expression Problem: > Given a set of types, and a set of operations on these types, is it possible > to add new operations on the existing types, and new types to the existing > operations, without modifying existing code? Open-methods solve the Expression Problem by making it possible to define free virtual functions, i.e. virtual functions that exist outside of a class. They also help reduce coupling. Open-methods are often called "multi-methods", because they typically make it possible to select an overrider on the basis of more than one argument (as this library does). Nice, but this is a distraction. Observations show that single dispatch largely outnumbers multiple dispatch in real systems, even in languages that natively support multi-methods (Common Lisp, Clojure, Julia, Dylan, TADS, Cecil, Diesel, Nice, etc). "Multi" is just the cherry on the "open" cake. Bjarne Stroustrup wanted open-methods in C++ almost from the beginning. In D&E he writes: > I repeatedly considered a mechanism for a virtual function call based on more > than one object, often called multi-methods. [...] Since about 1985, I have > always felt some twinge of regret for not providing multi-methods. > Stroustrup, 1994, The Design and Evolution of C++, 13.8. Circa 2007, he tried to bring open-methods into the standard, unfortunately without success, to his enduring regret. Decades later he writes: > In retrospect, I don’t think that the object-oriented notation (e.g., x.f(y)) > should ever have been introduced. The traditional mathematical notation f(x,y) > is sufficient. As a side benefit, the mathematical notation would naturally > have given us multi-methods, thereby saving us from the visitor pattern > workaround. > Stroustrup, 2020, Thriving in a Crowded and Changing World: C++ 2006–2020. This is what this library is all about: f(x, y), and getting rid of visitors. It closely follows the design described in the papers by Stroustrup and his PhD students Peter Pirkelbauer and Yuriy Solodkyy. Method dispatch is *fast*. It uses v-tables similar to native virtual functions, and it can match their performance. The library also provides additional features: a mechanism to call the next most specialized overrider, support for smart pointers, customization points for alternative RTTI systems, error handling, tracing, etc. The library requires C++17 or above. It supports virtual and multiple inheritance, excluding repeated inheritance. For evaluation purposes, I prepared a repository with a library adapted to Boost naming conventions: https://github.com/jll63/Boost.OpenMethod. The documentation is here: https://jll63.github.io/Boost.OpenMethod. Here are a few examples from the tutorial on Compiler Explorer: * Hello World: https://godbolt.org/z/9hv8oE8zd * AST - combining virtual_ptr and std::unique_ptr: https://godbolt.org/z/cPjzfanc8 * Intrusive vptr: https://godbolt.org/z/87h9zv7dK * Policy for throwing exceptions: https://godbolt.org/z/nEYWGsPc5 If you like what you see, please consider endorsing the library. Thanks, Jean-Louis Leroy

6 11

[Release] Master branch is now closed for the beta release
by Marshall Clow 09 Mar '25

09 Mar '25

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

1 0

[release] Master branch closes for the 1.88.0 beta release on SATURDAY (March 8)
by Ion Gaztañaga 06 Mar '25

06 Mar '25

Hi, Due to some unexpected delays, the master branch will close on SATURDAY (March 8). — The Release Managers

1 0

MAP and Vector clear is not releasing memory
by Murali Kishore 26 Feb '25

26 Feb '25

Hi, map and vector stored in shared memory using boost apis and called clear to release memory. when i insert same key i see old data present. want to check using boost map.clear or vec.clear is not removing content. Example: pod_list[] (vector contains following 3 members) pod_info { pod_id du_map. cell_map. } Step 1: Added elements Step 2: pod_list.clear(); Step 3: observed no elements in pod_list empty Step 4: Added only key pod_info.pod_id = 1; pod_list.insert(pod_info); Step 5: i see old content map to this pod_id. after this expecting du_map.size and cell_map size is empty. but du_map,cell_map content is same as before clear want to check is clear will not remove memory? is any other best way to clean this vector. -- Regards, Murali Kishore

2 2

Master branch now closed for new libraries and breaking changes
by Marshall Clow 26 Feb '25

26 Feb '25

Welcome to the start of the 1.88.0 release cycle. The release branch is now closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries without release manager review. The next deadline is next Wednesday, when the release branch will be closed for major changes. As always, the calendar is here: https://www.boost.org/development/index.html — The release managers

2 1

Master branch closing for major changes TOMORROW
by Marshall Clow 26 Feb '25

26 Feb '25

After tomorrow: Release branch closed for major code changes. Still open for serious problem fixes and docs changes without release manager review. Next milestone:March 5th - Release closed for all changes (for 1.88.0 beta 1) Calendar is here: https://www.boost.org/development/ — The release managers

1 0

observing crash during find_or_construct
by Murali Kishore 25 Feb '25

25 Feb '25

Hi all, Now i have moved most of the containers into shared memory, i am Observing crash at random places while calling find_or_construct api, trace as below, what might be reasons for this behaviour and how to get more debug info in these type of errors. #0 operator() (this=<optimized out>, b=..., i=...) at /staging/cu/x86/include/boost/interprocess/indexes/iset_index.hpp:94 #1 operator()<boost::interprocess::ipcdetail::intrusive_compare_key<char> > (this=<optimized out>, key2=..., nonkey1=...) at /staging/cu/x86/include/boost/intrusive/detail/tree_value_compare.hpp:157 #2 operator()<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::interprocess::offset_ptr<boost::intrusive::compact_rbtree_node<boost::interprocess::offset_ptr<void> >, long int, long unsigned int, 0ul> > (this=<optimized out>, t2=..., t1=...) at /staging/cu/x86/include/boost/intrusive/detail/key_nodeptr_comp.hpp:106 #3 insert_unique_check<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::intrusive::detail::key_nodeptr_comp<boost::interprocess::iset_index<boost::interprocess::ipcdetail::index_config<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family> > >::intrusive_key_value_less, boost::intrusive::bhtraits<boost::interprocess::ipcdetail::intrusive_value_type_impl<boost::intrusive::generic_hook<(boost::intrusive::algo_types)5, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, boost::intrusive::dft_tag, (boost::intrusive::link_mode_type)1, (boost::intrusive::base_hook_type)3>, char, unsigned long>, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, (boost::intrusive::link_mode_type)1, boost::intrusive::dft_tag, 3u>, boost::move_detail::identity<boost::interprocess::ipcdetail::intrusive_value_type_impl<boost::intrusive::generic_hook<(boost::intrusive::algo_types)5, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, boost::intrusive::dft_tag, (boost::intrusive::link_mode_type)1, (boost::intrusive::base_hook_type)3>, char, unsigned long> > > > (pdepth=0x0, commit_data=..., comp=..., key=..., header=...) at /staging/cu/x86/include/boost/intrusive/bstree_algorithms.hpp:1014 #4 boost::intrusive::bstbase2<boost::intrusive::bhtraits<boost::interprocess::ipcdetail::intrusive_value_type_impl<boost::intrusive::generic_hook<(boost::intrusive::algo_types)5, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, true>, boost::intrusive::dft_tag, (boost::intrusive::link_mode_type)1, (boost::intrusive::base_hook_type)3>, char, unsigned long>, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, true>, (boost::intrusive::link_mode_type)1, boost::intrusive::dft_tag, 3u>, void, void, (boost::intrusive::algo_types)5, void>::insert_unique_check<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::interprocess::iset_index<boost::interprocess::ipcdetail::index_config<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul> > >::intrusive_key_value_less> (this=this@entry=0x7f035d1dc0a0, key=..., comp=..., commit_data=...) at /staging/cu/x86/include/boost/intrusive/bstree.hpp:499 #5 0x0000000001d8c7a1 in insert_check<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::interprocess::iset_index<boost::interprocess::ipcdetail::index_config<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family> > >::intrusive_key_value_less> (commit_data=..., key=..., this=0x7f035d1dc098, comp=...) at /staging/cu/x86/include/boost/intrusive/set.hpp:232 #6 insert_check (commit_data=..., key=..., this=0x7f035d1dc098) at /staging/cu/x86/include/boost/interprocess/indexes/iset_index.hpp:138 #7 priv_generic_named_construct<char> (type=1 '\001', is_intrusive=..., index=..., table=..., dothrow=true, try2find=true, num=1, name=0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", this=<optimized out>, this=<optimized out>) at /staging/cu/x86/include/boost/interprocess/segment_manager.hpp:1096 #8 priv_generic_construct (table=..., dothrow=true, try2find=true, num=1, name=0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", this=0x7f035d1dc010) at /staging/cu/x86/include/boost/interprocess/segment_manager.hpp:760 #9 generic_construct<bool> (table=..., dothrow=true, try2find=true, num=1, name=0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", this=0x7f035d1dc010) at /staging/cu/x86/include/boost/interprocess/segment_manager.hpp:704 #10 boost::interprocess::ipcdetail::named_proxy<boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>, bool, false>::operator()<bool>(bool&&) const (this=<optimized out>) at /staging/cu/x86/include/boost/interprocess/detail/named_proxy.hpp:132 #11 0x0000000001fbb6c8 in gnb::gnb_mgr_neighbour::gnb_mgr_neighbour (this=0x7f033815fc50, segment_manager=0x7f035d1dc010, id=<optimized out>) at /../src/gnb_mgr_db_neighbour.cpp:76 #12 0x0000000002062888 in gnb::gnb_mgr_anr_nrt::add_anr_gnb_mgr_neighbour_target (this=0x7f033815a4c0, neighbour_gnb_id=108, neighbour_xnc_ip_address=..., type=0, neighbour_tac=101, amf_id=3, neighbour_plmn_id=...) at /../src/gnb_mgr_anr_nrt.cpp:1415 #13 0x0000000002325356 in gnb::gnb_mgr_amf::amf_fsm::process_downlink_ran_configuration_transfer (this=this@entry=0x7f035d1e0618, gnb_mgr_amf=gnb_mgr_amf@entry=0x7f0338109070, msg=msg@entry=0x7f0338161bd0) at /../src/gnb_mgr_db_amf.cpp:2851 #14 0x000000000235518b in gnb::gnb_mgr_amf::amf_fsm::process_amf_state_ng_setup_complete (this=<optimized out>, event=gnb::gnb_mgr_amf::EVENT_DOWNLINK_RAN_CONFIGURATION_TRANSFER, gnb_mgr_amf=0x7f0338109070, msg=0x7f0338161bd0, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>) at /../src/gnb_mgr_db_amf.cpp:3122 #15 0x0000000002362a01 in gnb::gnb_mgr_amf::amf_fsm::process_amf_fsm (this=<optimized out>, event=gnb::gnb_mgr_amf::EVENT_DOWNLINK_RAN_CONFIGURATION_TRANSFER, gnb_mgr_amf=0x7f0338109070, msg=0x7f0338161bd0, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>) at /../src/gnb_mgr_db_amf.cpp:4713 #16 0x0000000002362ee7 in gnb::gnb_mgr_amf::process_amf_current_state (this=<optimized out>, event=event@entry=gnb::gnb_mgr_amf::EVENT_DOWNLINK_RAN_CONFIGURATION_TRANSFER, gnb_mgr_amf=<optimized out>, msg=msg@entry=0x7f0338161bd0, this=<optimized out>) at /../src/gnb_mgr_db_amf.cpp:4820 #17 0x00000000021906b0 in gnb::gnb_mgr_ng_msg_proc::process_downlink_ran_configuration_transfer (this=<optimized out>, sctp_common_msg_rx_ind_info=sctp_common_msg_rx_ind_info@entry=0x7f033c040430) at /../src/gnb_mgr_ng_msg.cpp:1456 #18 0x00000000021a20c9 in gnb::gnb_mgr_ng_msg_proc::process_ng_msg (this=this@entry=0x7f03504a4640, sctp_common_msg_rx_ind_info=sctp_common_msg_rx_ind_info@entry=0x7f033c040430) at /../src/gnb_mgr_ng_msg.cpp:2199 #19 0x00000000024d991c in gnb::gnb_mgr_msg_hdlr::process_sctp_common_msg_rx_ind (this=<optimized out>, sctp_common_msg_rx_ind=0x7f033c040430) at /../src/gnb_mgr_msg_hdlr.cpp:3807 #20 0x0000000001db5ea2 in gnb::common_cntrl_thread::process_message (this=0xd825da0, message=0x7f033c120d50) at ../src/common_cntrl_thread.cpp:2418 #21 0x0000000001ceaeec in ngp::comm_thread::run (this=0xd825da0) at /include/ngp_comm_thread.h:220 #22 0x0000000002758e07 in thread_entry_function (param=0xd825da0) at /thread/build/../src/ngp_sys_thread.cpp:111 #23 ngp::thread_start (param=0xd825da0) at /thread/build/../src/ngp_sys_thread.cpp:124 #24 0x00007f036ba90ea5 in start_thread () from /lib64/libpthread.so.0 #25 0x00007f036b7b9b0d in clone () from /lib64/libc.so.6 #0 operator() (this=<optimized out>, b=..., i=...) at /staging/cu/x86/include/boost/interprocess/indexes/iset_index.hpp:94 blen = <optimized out> #1 operator()<boost::interprocess::ipcdetail::intrusive_compare_key<char> > (this=<optimized out>, key2=..., nonkey1=...) at /staging/cu/x86/include/boost/intrusive/detail/tree_value_compare.hpp:157 No locals. #2 operator()<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::interprocess::offset_ptr<boost::intrusive::compact_rbtree_node<boost::interprocess::offset_ptr<void> >, long int, long unsigned int, 0ul> > (this=<optimized out>, t2=..., t1=...) at /staging/cu/x86/include/boost/intrusive/detail/key_nodeptr_comp.hpp:106 No locals. #3 insert_unique_check<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::intrusive::detail::key_nodeptr_comp<boost::interprocess::iset_index<boost::interprocess::ipcdetail::index_config<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family> > >::intrusive_key_value_less, boost::intrusive::bhtraits<boost::interprocess::ipcdetail::intrusive_value_type_impl<boost::intrusive::generic_hook<(boost::intrusive::algo_types)5, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, boost::intrusive::dft_tag, (boost::intrusive::link_mode_type)1, (boost::intrusive::base_hook_type)3>, char, unsigned long>, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, (boost::intrusive::link_mode_type)1, boost::intrusive::dft_tag, 3u>, boost::move_detail::identity<boost::interprocess::ipcdetail::intrusive_value_type_impl<boost::intrusive::generic_hook<(boost::intrusive::algo_types)5, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, boost::intrusive::dft_tag, (boost::intrusive::link_mode_type)1, (boost::intrusive::base_hook_type)3>, char, unsigned long> > > > (pdepth=0x0, commit_data=..., comp=..., key=..., header=...) at /staging/cu/x86/include/boost/intrusive/bstree_algorithms.hpp:1014 depth = <optimized out> y = { internal = { m_offset = 769371974, alignment_helper = { dummy = "F\257\333-\000\000\000" } } } left_child = true not_present = <optimized out> h = { internal = { m_offset = 215197376, alignment_helper = { dummy = "\300\246\323\f\000\000\000" } } } x = { internal = { m_offset = 769371958, alignment_helper = { dummy = "6\257\333-\000\000\000" } } } prev = { internal = { m_offset = 215199488, alignment_helper = { dummy = "\000\257\323\f\000\000\000" } } } #4 boost::intrusive::bstbase2<boost::intrusive::bhtraits<boost::interprocess::ipcdetail::intrusive_value_type_impl<boost::intrusive::generic_hook<(boost::intrusive::algo_types)5, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, true>, boost::intrusive::dft_tag, (boost::intrusive::link_mode_type)1, (boost::intrusive::base_hook_type)3>, char, unsigned long>, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, true>, (boost::intrusive::link_mode_type)1, boost::intrusive::dft_tag, 3u>, void, void, (boost::intrusive::algo_types)5, void>::insert_unique_check<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::interprocess::iset_index<boost::interprocess::ipcdetail::index_config<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul> > >::intrusive_key_value_less> (this=this@entry=0x7f035d1dc0a0, key=..., comp=..., commit_data=...) at /staging/cu/x86/include/boost/intrusive/bstree.hpp:499 ret = { first = { internal = { m_offset = 769371910, alignment_helper = { dummy = "\006\257\333-\000\000\000" } } }, second = true } #5 0x0000000001d8c7a1 in insert_check<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::interprocess::iset_index<boost::interprocess::ipcdetail::index_config<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family> > >::intrusive_key_value_less> (commit_data=..., key=..., this=0x7f035d1dc098, comp=...) at /staging/cu/x86/include/boost/intrusive/set.hpp:232 No locals. #6 insert_check (commit_data=..., key=..., this=0x7f035d1dc098) at /staging/cu/x86/include/boost/interprocess/indexes/iset_index.hpp:138 No locals. #7 priv_generic_named_construct<char> (type=1 '\001', is_intrusive=..., index=..., table=..., dothrow=true, try2find=true, num=1, name=0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", this=<optimized out>, this=<optimized out>) at /staging/cu/x86/include/boost/interprocess/segment_manager.hpp:1096 key = { mp_str = 0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", m_len = 31 } insert_ret = { first = { static stateful_value_traits = false, members_ = { nodeptr_ = { internal = { m_offset = 1, alignment_helper = { dummy = "\001\000\000\000\000\000\000" } } } } }, second = false } intrusive_hdr = <optimized out> block_info = { m_value_bytes = 1, m_num_char = 31, m_value_alignment = 1 '\001', m_alloc_type_sizeof_char = 33 '!' } commit_data = { link_left = 112, node = { internal = { m_offset = 1, alignment_helper = { dummy = "\001\000\000\000\000\000\000" } } } } hdr = <optimized out> ptr = <optimized out> name_ptr = <optimized out> it = { static stateful_value_traits = false, members_ = { nodeptr_ = { internal = { m_offset = 1, alignment_helper = { dummy = "\001\000\000\000\000\000\000" } } } } } buffer_ptr = <optimized out> v_eraser = { m_cont = @0x0, m_index_it = { static stateful_value_traits = false, members_ = { nodeptr_ = { internal = { m_offset = 0, alignment_helper = { dummy = "\000\000\000\000\000\000\000" } } } } }, m_erase = 208 } #8 priv_generic_construct (table=..., dothrow=true, try2find=true, num=1, name=0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", this=0x7f035d1dc010) at /staging/cu/x86/include/boost/interprocess/segment_manager.hpp:760 No locals. #9 generic_construct<bool> (table=..., dothrow=true, try2find=true, num=1, name=0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", this=0x7f035d1dc010) at /staging/cu/x86/include/boost/interprocess/segment_manager.hpp:704 No locals. #10 boost::interprocess::ipcdetail::named_proxy<boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>, bool, false>::operator()<bool>(bool&&) const (this=<optimized out>) at /staging/cu/x86/include/boost/interprocess/detail/named_proxy.hpp:132 ctor_obj = <unknown type in /bin/gnb_cu_cp_gnb_mgr, CU 0x14204b9, DIE 0x1522041> -- Regards, Murali Kishore

1 0

Introduction & Inquiry About GSoC 2025 Participation
by Eslam Samy 13 Feb '25

13 Feb '25

Dear Boost Community, I hope you’re all doing well. My name is Eslam, and I’m a student at Al-Azhar university in Cairo,Egypt, I have a strong interest in open source development. I’ve been programming in C and C++ for several years, primarily solving algorithmic challenges on platforms like Codeforces and LeetCode (2000+ problems solved), but I haven’t yet had the opportunity to contribute to large open-source projects. I recently joined this mailing list because I want to get involved in open-source development, and Boost is one of the most respected C++ projects out there. I would love to learn from this community and contribute in any way I can. I also wanted to ask: Does Boost plan to participate in Google Summer of Code (GSoC) this year? If so, I’d be very interested in learning about potential project ideas and how I can get started with contributions. Looking forward to hearing from you all and excited to be part of this community! Best regards, Eslam Samy GitHub: eslamsamy226 LinkedIn : https://www.linkedin.com/in/eslam-samy-097893220/

2 1

compilation time increased
by Murali Kishore 12 Feb '25

12 Feb '25

Hi, Observing compilation time increase when i include boost interprocess headers. is there a way to reduce compilation time as this time going more than hours in large project. -- Regards, Murali Kishore

4 4

asio::strand: Order of execution
by Georg Gast 11 Feb '25

11 Feb '25

Hi, If I use a asio::strand and post() there multiple function objects, are they executed in the same order or is the order of execution not specified? I think to use it as a work queue but I need them to be processed in sequence... Thx Georg

5 9

[review] [sqlite]
by Richard Hodges 04 Feb '25

04 Feb '25

Dear All, Surprise! The Boost formal review of the Boost SQLITE library starts *TODAY*, taking place from November 13th, 2024 to November 22nd, 2024 (inclusive). I apologise profusely for springing this on you without prior warning. The error is entirely mine. I am extending the period by one day to compensate. The library is authored by Klemens Morgenstern (@klemens-morgenstern in the CppLang slack). Documentation: https://klemens.dev/sqlite/ <https://anarthal.github.io/mysql/index.html> Source: https://github.com/klemens-morgenstern/sqlite <https://github.com/anarthal/mysql/> >From the documentation: boost.sqlite is a simple to use C++ sqlite library. It provides a modern interface using facilities like error_code, views (e.g. for blobs) and the ability to use boost.describe or boost.pfr for parameterised queries. Supported features include: - typed queries - prepared statements - json support - custom functions (scalar, aggregate, windows) - event hooks - virtual tables SQLite provides an excellent C-API, so this library does not attempt to hide, but to augment it. Please provide in your review information you think is valuable to explain your choice to ACCEPT or REJECT including SQLITE as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - Will the library bring additional out-of-the-box utility to Boost? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - Will the choice of API abstraction model ease the development of software that must talk to a SQLITE database? - Are there any immediate improvements that could be made after acceptance, if acceptance should happen? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Thank you for your efforts in the Boost community. They are very much appreciated. Richard Hodges - review manager of the proposed Boost.SQLITE library Klemens is often available on CppLang Slack and of course by email should you require any clarification not covered by the documentation, as am I.

17 61

Decimal Review Result and Summary.
by John Maddock 02 Feb '25

02 Feb '25

First off I'd like to thank Matt and Chris for submitting the library for review, and for all the reviewers who submitted comments. My apologies for not posting this sooner, but this has been a difficult review to reach a definite result on. First the headline result: the result of the review is INDETERMINATE. What this means in practice: I'd like to encourage Matt and Chris to come back for a mini-review at a later date which should focus exclusively on the open issues listed below. I forget which library we applied this to in the past, but I believe the result is not without precedent. I note that a greater weight of reviews, and/or a clearer path forward may well have tipped the balance here. And of course as someone who's worked with Matt and Chris, I may well be being over-harsh in order to avoid bias... or perhaps I'm just over thinking the whole thing... In my notes below, I've split my comments into: * "Settled Issues", these were issues that were raised at some point but found not to be true issues. * "Todo", straightforward usability and implementation issues such as we get from any review process. I've filed matching GitHub issues for each of these. * "Open", these are the harder knotty problems, where it's not clear (yet) what the solution is. RATIONALE: we had five reviews (4 public, one direct to me), of which 4 were generally positive, and one was for reject. In addition, some of the positive reviews were directly contradictory in the direction they thought the library should progress in ("we should only support the fast types", vs "we should only support the fixed width types" etc). There were also some conditions for acceptance - mostly performance based - where it's not clear whether the objectives are possible in a sane time-frame. For example the often referenced Intel C library is frankly huge (source files > 6Mb in size) and makes heavy use of the "every function is a macro" C idiom, which at least for me renders the code virtually unreadable. As things stand I consider it unreasonable to ask the authors to replicate that work. In late breaking news, I also hear from Matt that GCC and IBM both "cheat" by using (mutually incompatible) non-IEEE binary encodings. There is also the "do we actually need decimal arithmetic" question - it is clear that many people think we do - there have been repeated attempts from researchers at IBM, Intel and others to push this towards standardization, in addition to some (rather patchy) hardware support. It's in C23, which means eventually C++ compiler support will be required too. Oh and python has a decimal library. However the authors need to articulate the case better - the killer application seems to be exact round tripping from human-readable and machine representations (ie exact representation of human data input). John Maddock (Decimal Library Review Manager) OPEN ISSUES ~~~~~~~~~~~ The case for decimal floating point needs to be better made - despite support from IBM and Intel, plus repeated standardization efforts, true killer examples seem to be thin on the ground. Perhaps liaison with other experts in the field would be helpful here (I note that Robert Klarer at IBM and also once around these parts has been involved in decimal proposals, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1977.html)? Should arithmetic operations always be performed on the performance optimized forms? If so, perhaps storage optimized forms should have no operators (or their operators return the unpacked versions)? Review managers note: can we use DEC_EVAL_METHOD to set behavior here? How do we address the performance gap? Add the option to wrap the Intel library? Rewrite using the same methodology as Intel (this looks like a truly massive amount of work)? Several reviewers make this a condition of acceptance however. Should we use _fast integers or width specific ones? The answer appears to be platform specific. Perhaps it's a question of changing the correct instances of _fast integers rather than all of them? Should we abolish the _fast types and only provide fixed-width std compliant types: this is the forward looking option in line with what the standards are doing... but it directly contradicts the requests of some other reviewers. SETTLED ISSUES ~~~~~~~~~~~~~~ The decimal32 decimal64 names etc are reserved by various standards especially IEEE-754, we need to stick to those names. Over long literals are acceptable without warning or error, though a static warning facility would be nice. One reviewer suggests removing BOOST_DECIMAL_FAST_MATH, however as it performs similar optimizations to other libraries / compiler options, it looks reasonable to stay if the authors wish. One reviewer suggested shortening the namespace names - this is a tricky one, I see the issue, but we have a tradition (rightly or wrongly) for long_descriptive_names in boost. Plus there are always using declarations and/or namespace aliases. I will leave this to the authors to decide. long/int overloads of scalbln are fine by me as these are std mandated, however the reviewer makes a valid point that these are useful only on 16 bit platforms (I do note that the library is intended to be micro-controller compatible though, so this may well be an issue there). One reviewer suggests passing arguments by value is a mistake especially for 128 bit types, other reviewers refuted this. Other than some experimentation / double checking on windows and non-Intel platforms this does not appear to be an issue in practice. Suggest no change unless the double checks prove otherwise, a comment in the source or the design rationale may well be welcome. One reviewer suggested using CLZ in num_digits, but this has been checked and is slower (a comment in the source to that effect would be welcome. Note that std::lower_bound is not constexpr until C++26. REQUESTED CHANGES ~~~~~~~~~~~~~~~~~ Literals should be in their own namespace. https://github.com/cppalliance/decimal/issues/827 Allow implicit conversions for all conversions which do not lose precision: https://github.com/cppalliance/decimal/issues/828 Remove sprint support. https://github.com/cppalliance/decimal/issues/829 Split into "use what you need" smaller headers, in particular iostream and std lib support code should be in separate optional headers rather than in #ifdef blocks. https://github.com/cppalliance/decimal/issues/830 I'm also not convinced about the value added by the other cstdio functions, namely printf, fprintf and snprintf. They only support decimal arguments. This means that printf("Value for id=%s is %H", id, value) is an error if id is a const char*. Integers work because they are cast to decimal types, which I found surprising, too. Given an int i, printf("Value for %x is %H", i, value) works but doesn't apply the hex specifier. The integer is promoted to a decimal type, which is then printed. I'd have expected the latter to be a compile-time error. I'd say that this will be the case if you replace std::common_type by std::conjunction as Peter suggested. https://github.com/cppalliance/decimal/issues/831 Are concept names supposed to be public? If they are, please document them as regular entities. If they are not, please move them into the detail namespace. https://github.com/cppalliance/decimal/issues/832 Collected documentation improvements: https://github.com/cppalliance/decimal/issues/833 Do the exponent_type typedefs need to be public? Do they need to be 64 bit? I suspect the latter is all about extracting the bits from the representation, and the former is a convenience to avoid a long list of friends - although the list doesn't look *that* long? If they remain public then a comment in the source with rationale would suffice. https://github.com/cppalliance/decimal/issues/834 Can we add (possibly explicit) constexpr construction from string literal? https://github.com/cppalliance/decimal/issues/835 There is an undocumented public constructor: constexpr decimal32(bool coeff, T exp, bool sign = false) noexcept; which appears to be a mistaken addition? https://github.com/cppalliance/decimal/issues/836 I wonder if constexpr decimal32(T coeff, T2 exp, bool sign = false) noexcept; is under-constrained? The sign argument appears to be superfluous given that coeff can be negative, and we know up front the size of integer required to represent the coefficient and exponent so we might as well make this a non-template: smaller integer arguments will get promoted and larger arguments will quite correctly issue a warning (I wouldn't use a type smaller than int though, otherwise the things get altogether too picky): https://github.com/cppalliance/decimal/issues/837 There are a few places where pow10 is used with a constexpr argument, but while the function is constexpr it is not used in a constexpr context. The example picked up from the review was auto res_sig {(static_cast<unsigned_int128_type>(lhs_sig) * static_cast<unsigned_int128_type>(rhs_sig)) / pow10(static_cast<unsigned_int128_type>(13))}; in mul_impl.hpp but there may be others. https://github.com/cppalliance/decimal/issues/838 Consider using delegating constructors in for example constexpr decimal128::decimal128(bool coeff, T exp, bool sign) (if we keep this... but check for other opportunities). https://github.com/cppalliance/decimal/issues/839 Ensure that +0 and -0 are equivalent. https://github.com/cppalliance/decimal/issues/840 Make uint128 a non-detail type given that it is used in public interfaces. Such a shame that it can't be a real std::uint128_t, but perhaps a conversion operator could be provided when the type is available? https://github.com/cppalliance/decimal/issues/841 Rationalize traits class usage to make the code easier to read: https://github.com/cppalliance/decimal/issues/842 Code duplication: comparison operators calling into `equal_parts_impl()` for `decimal32_fast`, but the definition being placed directly into the comparison operator functions for `decimal64_fast` and decimal128_fast`. For me, this makes it seem like these 3 types must be implementing the comparison operators in different ways, when in reality they are doing exactly the same calculation, implemented in 3 separate places. https://github.com/cppalliance/decimal/issues/843 Code duplication with `bias_v`: https://github.com/cppalliance/decimal/issues/844 Explicit conversions need much better documentation for overflow behavior - I had to look at the source for to_integral to figure this out - I'm also wondering if returning zero on error is the right solution or if the result should be saturated? https://github.com/cppalliance/decimal/issues/845 Remove the footgun of lossy conversion from decimal floating point types. https://github.com/cppalliance/decimal/issues/846

6 9

Decimal: Formal review begins.
by John Maddock 31 Jan '25

31 Jan '25

The review of the proposed Decimal Number library by Matt Borland and Chris Kormanyos begins today and runs until 22nd Jan. You will find documentation here: https://cppalliance.org/decimal/decimal.html And the code repository is here: https://github.com/cppalliance/decimal/ Boost.Decimal is an implementation of IEEE 754 <https://standards.ieee.org/ieee/754/6210/> and ISO/IEC DTR 24733 <https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2849.pdf> Decimal Floating Point numbers. The library is header-only, has no dependencies, and requires C++14. Please provide feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? Do you already use it in industry? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Ensure to explicitly include with your review: ACCEPT, REJECT, or CONDITIONAL ACCEPT (with acceptance conditions).header-only, has no dependencies, and requires C++14. Best, John Maddock (review manager).

18 94

Author assistance for WG21 display content
by Robert Beeston 30 Jan '25

30 Jan '25

Hello everyone, My name is Rob Beeston, and I’m the Product and Creative Director for C++ Alliance. I’m currently making arrangements for the upcoming WG21 event, and could use some help from some of the authors. We will be making posters, similar to this mockup ( https://downloads.cppalliance.org/images/boost-poster.png) to highlight the following libraries at the event: Hash2 Math Parser Scope Unordered Each poster would need a brief description, a longer explanation (perhaps 1-2 short paragraphs of what it does and/or how it works) and a code snippet that would best represent how to use it. Thanks and I’m looking forward to working with you. Rob

4 6

Interest for C++20 modules support of boost officially
by Chuanqi Xu 29 Jan '25

29 Jan '25

Hi Boost Developers, I am Chuanqi Xu, the maintainer for modules & serialization in clang and also a fan of C++20 modules. The post itself was motivated by a discussion (https://cpplang.slack.com/archives/C27KZLB0X/p1734335425348809 <https://cpplang.slack.com/archives/C27KZLB0X/p1734335425348809 >). You don’t need to read it if you’re not interested. I’ll try to make the post itself self contained. The original story comes from a high quality experiment for C++20 modules in boost (https://anarthal.github.io/cppblog/modules2 <https://anarthal.github.io/cppblog/modules2 >). The blog reads pretty good to me. However, anarthal (the author) told me later that the process of supporting modules in boost got suspended since the authors (or the maintainers) don’t want it since no one is going to use them. And if I want it, I need to send a mail here. Then this is the beginning of the story. First of first, I want to emphasize that “no one is going to use them” is not true. We’ve already used C++20 modules at larger scale internally for roughly a year. For boost (and other third party libraries), we choose to wrap a module ourselves as a workaround (with some compiler extensions to ease the refacotoring, but we don’t like it. We still want standard behavior). We didn’t reach out since we feel boost will support C++20 modules later or sooner so we don’t need to do anything specially. (Maybe we were wrong. We didn’t understand the ecosystem enough). Until yesterday, I just knew that boost didn’t know such needs. Before I wrote this email, I wondered a lot of words to emphasize that our need are a good example and the users of closed source are important users too. But just now, I searched the use of boost in modules in GitHub. I just realized I can show it (the importance of C++20 modules support for boost) much easily with the open source world. I searched `boost path:*.cppm` in GitHub and got the following list: https://github.com/infiniflow/infinity/blob/fa922afd58c973a9a317d2c09ad8cea… <https://github.com/infiniflow/infinity/blob/fa922afd58c973a9a317d2c09ad8cea… > https://github.com/ossia/score/blob/0ce6f62a97651a1248a92b3e13ce6ede10341d1… <https://github.com/ossia/score/blob/0ce6f62a97651a1248a92b3e13ce6ede10341d1… > https://github.com/RichardLuo0/make-dot-cpp/blob/e2ef10fd43060a2b56fc8f87f1… <https://github.com/RichardLuo0/make-dot-cpp/blob/e2ef10fd43060a2b56fc8f87f1… > https://github.com/slaakko/cmajor-mod/blob/32e6eb8dc099b395fa751340de96f478… <https://github.com/slaakko/cmajor-mod/blob/32e6eb8dc099b395fa751340de96f478… > https://github.com/df-com/dragonfly/blob/9dfcbc1153f292eb8581f1df7459600cc3… <https://github.com/df-com/dragonfly/blob/9dfcbc1153f292eb8581f1df7459600cc3… > https://github.com/nofe1248/Helium/blob/92ec4452b8c05e6d86c972f843196a4392a… <https://github.com/nofe1248/Helium/blob/92ec4452b8c05e6d86c972f843196a4392a… > https://github.com/LagrangeDev/liblagrange/blob/10e3b48f8d47fd65de00b14cfed… <https://github.com/LagrangeDev/liblagrange/blob/10e3b48f8d47fd65de00b14cfed… > https://github.com/yudaichen/feature-db/blob/e94ade969af682ed5dd25d70bf282b… <https://github.com/yudaichen/feature-db/blob/e94ade969af682ed5dd25d70bf282b… > This is not a complete list even for my search only and I believe there are other patterns to use boost with modules now (e.g., at least `*.cppm` is not the defacto suffix). And I also believe, from my experience as a C++ user, if boost provide modules, I may try to use it. But if boost didn’t provide it, maybe I won’t ask for it if I don’t want modules super bad. Since modules doesn’t add any new functionality actually. So most users may not ask for it explicitly. But if boost provides it, people may give it a try. The above text are the body of the post. I hope it can show it is needed. — Following of are some technical discussion for the extra maintainance burden by introducing modules. The conclusion is, I think, the burden is pretty low. Since modules are not complex to users. Different from other big features in C++, modules are pretty easy to understand. The complexity of modules are majorly on tools and the ecosystem. For programmers who don’t get involved to much to the ecosystem (or infrastructure), modules should be pretty easy to understand. For authors of libraries, after boost introduce modules, you only need to do 2 extra things: - In headers, add a macro (assume its name as BOOST_MODULE_EXPORT, which will be ‘export’ conditionally) to the entities that need to be exported. - In headers, include standard headers and other dependent headers conditionally so that we don’t include anything if the headers are in a module unit. e.g., https://github.com/boostorg/pfr/blob/f09e6aeae9d050897fff72b93d5f5e866cc5e1… <https://github.com/boostorg/pfr/blob/f09e6aeae9d050897fff72b93d5f5e866cc5e1… > then that’s roughly all you need for maintaining it at source level. For building and distributing related things, anarthal told me that the boost will handle it globally so the individual arthors don’t need to care about it. — In slack, there are some other discussion about module names and linking problems (https://cpplang.slack.com/archives/C27KZLB0X/p1734345716728609 <https://cpplang.slack.com/archives/C27KZLB0X/p1734345716728609 >). But I feel they are implementation details. I may not talk too much for that as a user at least now. And also there are opinions for configuration flags. These are the jobs of build systems (cmake is working on it). I think boost don’t need to worry for that. Similarly, at least libc++ has similar problems but libc++ still released std module. — Boost has a special position in the C++’s ecosystem. The most simple and impressive answer I’ve heard for the question “when can we start to use modules” is, “when boost makes it”. Thanks, Chuanqi

15 85

observing process blocked on find_or_construct
by Murali Kishore 28 Jan '25

28 Jan '25

Hi , We are trying interprocess scenario, one process created shared memory objects and killed and second process open the object using find_or_construct seeing this process blocked at getting lock. bt as shown below, #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x00007fa6b6733eb6 in _L_lock_941 () from /lib64/libpthread.so.0 #2 0x00007fa6b6733daf in __GI___pthread_mutex_lock (mutex=mutex@entry=0x7fa6b198b070) at ../nptl/pthread_mutex_lock.c:113 #3 0x0000000001bc3822 in lock (this=0x7fa6b198b070) at /x86/include/boost/interprocess/sync/posix/recursive_mutex.hpp:90 #4 lock (this=0x7fa6b198b070) at /x86/include/boost/interprocess/sync/interprocess_recursive_mutex.hpp:163 #5 scoped_lock (m=..., this=<synthetic pointer>) at /x86/include/boost/interprocess/sync/scoped_lock.hpp:81 #6 boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>::priv_generic_named_construct<char> (this=0x7fa6b198b010, type=<optimized out>, name=0x7ffde183ca20 "reported_slice_config_list", num=1, try2find=<optimized out>, dothrow=<optimized out>, table=..., index=..., is_intrusive=...) at /x86/include/boost/interprocess/segment_manager.hpp:1076 #7 0x0000000001bee007 in boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>::priv_generic_construct (this=<optimized out>, name=name@entry=0x7ffde183ca20 "reported_slice_config_list", num=num@entry=1, try2find=try2find@entry=true, dothrow=dothrow@entry=true, table=...) at /x86/include/boost/interprocess/segment_manager.hpp:760 #8 0x0000000001bf112d in generic_construct<boost::container::map<unsigned int, gnb::broadcast_plmn_list, std::less<unsigned int>, boost::interprocess::allocator<std::pair<unsigned int const, gnb::broadcast_plmn_list>, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, boost::interprocess::iset_index> > > > (table=..., dothrow=true, try2find=true, num=1, name=0x7ffde183ca20 "reported_slice_config_list", this=<optimized out>) at /x86/include/boost/interprocess/segment_manager.hpp:704 #9 operator()<std::less<unsigned int>, boost::interprocess::allocator<std::pair<unsigned int const, gnb::broadcast_plmn_list>, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long int, long unsigned int, 0ul>, 0ul>, boost::interprocess::iset_index> >&> (this=<optimized out>) at /x86/include/boost/interprocess/detail/named_proxy.hpp:132 please let me know in which cases this can be occured, we see first process also hangs in termination. -- Regards, Murali Kishore

3 3

End of Boost.Decimal Review
by John Maddock 25 Jan '25

25 Jan '25

The review of the proposed Decimal library has now ended - although given that there was a lot of lively discussion for me to sort through, there is still time to submit a late review if you wish. If I've counted correctly there were 5 reviews (4 on the list, one private): one firm reject and 4 conditional accept, plus many more people involved in the discussion than gave reviews. I have to be honest, I would have liked to have seen a couple more reviews in order to have reached a clearer consensus, so please bare with me while I sift through all the comments and try and reach a conclusion. My thanks to everyone who took part, and of course to Matt and Chris for submitting the library. Best, John.

1 0

GSoC 2025 Projects
by Matt Borland 24 Jan '25

24 Jan '25

All, In the modules thread and on Slack, I asked if Boost had a current plan for participation in GSoC 2025. I haven't received any responses yet, so I'll assume there isn't a plan. I'm wondering if anyone has: a) Projects they would like to propose for GSoC, and b) An interest in mentoring. Here are some ideas that I think could be beneficial and approachable: 1) A proof of concept for a Boost module, including distribution and installation processes, and potentially adding support to select libraries. This project could have easy access to the Clang and MSVC teams via their mentor it seems. 2) Bi-variate interpolation has been requested before in Math. ACM TOMS algorithms 751 and 761 could fit the bill, but their references are written in F77. A faithful translation and implementation of those papers would be a good start. 3) Chris Kormanyos and I are working on a cryptographic module that we intend to have certified under FIPS 140-3 and then propose to Boost. An extension of this could be a TLS project where a student provides a proof of concept with a generic file transfer server or similar that works securely with OpenSSL, and then also with our new module. I can mentor at least one of these projects. If anyone has past applications for the organization, please send a link or copies. We have until mid-Feb to apply as an organization, which I can do if no one else volunteers. Best, Matt

5 8